From Firewalls-Owner@GreatCircle.COM Sat Jan 1 16:31:24 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05983; Sat, 1 Jan 94 16:31:24 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05971; Sat, 1 Jan 94 08:31:14 PST Received: by relay.tis.com; id AA05787; Sat, 1 Jan 94 11:32:24 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma005785; Sat Jan 1 11:31:57 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA27519; Sat, 1 Jan 94 11:31:50 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA13190; Sat, 1 Jan 94 11:31:48 EST Date: Sat, 1 Jan 94 11:31:48 EST From: mjr@tis.com Message-Id: <9401011631.AA13190@otter.tis.com> To: Firewalls@GreatCircle.COM, dalewl%radian@[129.160.16.4] Subject: Re: Is there an FTP proxy that can also give local service? Cc: dalewl@zippy.radian.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Is there an FTP proxy server that also provides local FTP service to >the machine that hosts it? Yes, but it's still in test. I just added a hook (5 lines of code) in my ftpd that detects user@host addresses, and when it sees them, it execs the ftp-gw proxy from our toolkit, with a hot-wired user name. Works just great. I have not yet released the code because our folks that test stuff are still testing it. If anyone out there who is using our toolkit wants to test it, drop me a note. mjr. From Firewalls-Owner@GreatCircle.COM Mon Jan 3 16:47:05 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12945; Mon, 3 Jan 94 16:47:05 GMT Received: from nsco.network.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12938; Mon, 3 Jan 94 08:46:48 PST Received: from nscultrix2.network.com by nsco.network.com (5.61/1.34) id AA18096; Mon, 3 Jan 94 10:49:10 -0600 Received: by nscultrix2.network.com (5.57/Ultrix3.0-C) id AA26955; Mon, 3 Jan 94 10:44:40 CST Date: Mon, 3 Jan 94 10:44:40 CST From: dotytr@nscultrix2.network.com (Ted Doty) Message-Id: <9401031644.AA26955@nscultrix2.network.com> To: jim@tadpole.com, smb@research.att.com Subject: Re: Packet Filter Performance Cc: firewalls@greatcircle.com, lacoursj@uprc.com, mjr@tis.com, sob@harvard.edu Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk smb@research.att.com writes: > A long time ago, someone at Harvard cooked up two programs > running on semi-fast (at the time) PCs. The programs > were named 'hammer' and 'anvil'. Hammer was the source, anvil > was the sink. This individual then put various routers between > the two, and measured the packet rates he could obtain. In > the end he published pretty graphs, etc. > > I don't remember who he was, or where to get the graphs. Perhaps > someone with more time than I can find it via archie/... > > Jim > >Sounds like Scott Bradner's (sob@harvard.edu) router benchmark stuff. >Last time I asked, he'd done a few tests of filter performance, >but not many. If I'm reading the charts correctly, both Cisco and >Wellfleet routers were able to run at about full Ethernet speed >with 10 filters in place. I don't have any details of the filters >used, and in particular I don't know if he was filtering on port numbers, >or just on addresses. > The problem with all of this is what do you mean by a "filter". We've been working on this issue for better than six months, and it looks like your access policy definition is the key input in the performance test. For trivial policies, such as IP_SOURCE_ADDRESS in (foo, bar, baz) OK; most routers are "fast enough", whatever that means (small performance hits in most networks, probably ca. 50% hit in very highly stressed FDDI environments). The problem is, what is an interesting access policy? We have seen instances where brand-name routers drop by over 70% when the policy demands protecting two user communities. Further, it looks like the results of this test apply on a per-router basis, not a per-interface basis. 4000 pps isn't too bad if you're talking T1 access to the internet, but it stinks if you also have 3 or 4 ethernets in the same box. The world is much more interesting than any of us suspected. ;-) - Ted P.S. OBTW, Network Systems routers held up very well, thank you. -------------------------------------------------------------------------- Ted Doty, Network Systems Corporation | phone: +1 301 596-2270 8965 Guilford Road, Suite 250 | fax: +1 410 381-3320 Columbia, MD, 21046 USA | voice mail: (800) 233-1485 -------------------------------------------------------------------------- These opinions are my own, not necessarially those of Network Systems. From Firewalls-Owner@GreatCircle.COM Mon Jan 3 16:49:50 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12963; Mon, 3 Jan 94 16:49:50 GMT Received: from nsco.network.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12956; Mon, 3 Jan 94 08:49:41 PST Received: from nscultrix2.network.com by nsco.network.com (5.61/1.34) id AA18160; Mon, 3 Jan 94 10:54:37 -0600 Received: by nscultrix2.network.com (5.57/Ultrix3.0-C) id AA27058; Mon, 3 Jan 94 10:50:11 CST Date: Mon, 3 Jan 94 10:50:11 CST From: dotytr@nscultrix2.network.com (Ted Doty) Message-Id: <9401031650.AA27058@nscultrix2.network.com> To: firewalls@greatcircle.com, mjr@tis.com, netmaine@ansremote.com Subject: Re: Source-address spoofing Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Network Systems routers allow you to test for the presence of any IP option, and to allow or disallow the packet. There's also audit capability (sort of like syslog). - Ted -------------------------------------------------------------------------- Ted Doty, Network Systems Corporation | phone: +1 301 596-2270 8965 Guilford Road, Suite 250 | fax: +1 410 381-3320 Columbia, MD, 21046 USA | voice mail: (800) 233-1485 -------------------------------------------------------------------------- These opinions are my own, not necessarially those of Network Systems. From Firewalls-Owner@GreatCircle.COM Mon Jan 3 16:53:48 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13016; Mon, 3 Jan 94 16:53:48 GMT Received: from hsdndev.harvard.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13003; Mon, 3 Jan 94 08:53:41 PST Date: Mon, 3 Jan 94 11:54:50 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9401031654.AA09694@hsdndev.harvard.edu> To: dotytr@nscultrix2.network.com, jim@tadpole.com, smb@research.att.com Subject: Re: Packet Filter Performance Cc: firewalls@greatcircle.com, lacoursj@uprc.com, mjr@tis.com, sob@harvard.edu Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Ted, You are right to worry about this issue. The reason I've not done more complex filter tests is that in order to get a number of products to compair I have to go to the simple type of filter that most of them support. I ain't happy with that since I feel that the use of access filters to provide a 1st cut at security can be quite important. If you (or anyone) has some suggestions about just what type of filters that I should include in the next series of tests please let me know. Scott From Firewalls-Owner@GreatCircle.COM Mon Jan 3 16:54:56 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13032; Mon, 3 Jan 94 16:54:56 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13017; Mon, 3 Jan 94 08:54:44 PST Received: by relay.tis.com; id AA17491; Mon, 3 Jan 94 11:55:47 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma017481; Mon Jan 3 11:54:56 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA05160; Mon, 3 Jan 94 11:54:48 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA02089; Mon, 3 Jan 94 11:54:47 EST Date: Mon, 3 Jan 94 11:54:47 EST From: mjr@tis.com Message-Id: <9401031654.AA02089@otter.tis.com> To: dotytr@nscultrix2.network.com, firewalls@greatcircle.com, netmaine@ansremote.com Subject: Re: Source-address spoofing Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Network Systems routers allow you to test for the presence of any IP option, >and to allow or disallow the packet. There's also audit capability (sort >of like syslog). Do you support filtering on input, or is the filtering output based? I.e., I want to tell my router: "block any traffic coming in to network A or B through the T1 interface, if it claims to have originated from network A or B." mjr. From Firewalls-Owner@GreatCircle.COM Mon Jan 3 22:49:27 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15073; Mon, 3 Jan 94 22:49:27 GMT Received: from ileaf.com (ileaf.prospect.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15066; Mon, 3 Jan 94 14:49:20 PST Received: from leafusa.UUCP by ileaf.com (4.1/SMI-4.1) id AA26145; Mon, 3 Jan 94 17:50:24 EST Received: from buckhill.HQ.Ileaf.COM by HQ.Ileaf.COM (4.1/SMI-4.0-leafusa) for firewalls@GreatCircle.COM id AA05816; Mon, 3 Jan 94 17:43:05 EST Received: by buckhill.HQ.Ileaf.COM (4.1/SMI-4.0-hq) for firewalls@GreatCircle.COM id AA13897; Mon, 3 Jan 94 17:43:04 EST Date: Mon, 3 Jan 94 17:43:04 EST From: timg@buckhill.HQ.ileaf.com (Tim Giebelhaus) Message-Id: <9401032243.AA13897@buckhill.HQ.Ileaf.COM> To: firewalls@GreatCircle.COM Subject: Internet risk and advice Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm looking for some information about how to hook up to the internet and the risks of doing so. Basically, I have three questions: - What are the risks of connecting to the internet with a firewall - What recommendations do people have for firewall connections - What do people generally do about ftp access across their firewall I'm looking for some way to quantify the risk of an ethernet connection to the internet. I was hoping CERT could provide me with statistics about how many of different general configurations were broken into, but they do not keep those statistics. Does anyone have a way to quantify the risk of connecting to the internet with a well thought out firewall? I am looking for recommendations on how to set up a firewall. I have Practical Unix Security by Garfinkel and Spafford and I have been reading the discussion of this group (I've worked my way back to most of November now). There are a number of people who believe we should only have a serial line connection to the internet, so I am looking at as secure as practical ethernet connection to the internet. I understand the set up of the UNIX firewall and the use of a filtering router. I'm a bit fuzzy on a parimeter network (I understand the goal, but don't understand why the seperate C class address is needed). I understand the use of TCP Wrapper, COPS, and ISS. If there are other tools to securing the connection please send me mail about them. Any suggestions about how to use these tools to put together the most secure connection would also be appreciated. Finally, I am interested in the ftp problem which has been talked about. Do people generally just let the data connections for the second channel through or is there another solution besides the passive mode? Assuming I don't have control over remote ftpd progrmas, is there a way to control the risk of these data connections? I would appreciate any information which I can get. Please email to me at timg@ileaf.com. Thank you. From Firewalls-Owner@GreatCircle.COM Tue Jan 4 08:13:03 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA17113; Tue, 4 Jan 94 08:13:03 GMT Received: from zinder.meteo.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA17106; Tue, 4 Jan 94 00:12:48 PST Received: by zinder.meteo.fr id AA22066 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Tue, 4 Jan 1994 09:13:27 GMT From: Remy Giraud Message-Id: <199401040913.AA22066@zinder.meteo.fr> Subject: Re: Source-address spoofing To: mjr@tis.com Date: Tue, 4 Jan 94 9:13:26 GMT Cc: dotytr@nscultrix2.network.com, firewalls@greatcircle.com, netmaine@ansremote.com In-Reply-To: <9401031654.AA02089@otter.tis.com>; from "mjr@tis.com" at Jan 3, 94 11:54 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > >Network Systems routers allow you to test for the presence of any IP option, > >and to allow or disallow the packet. There's also audit capability (sort > >of like syslog). > > Do you support filtering on input, or is the filtering > output based? > > I.e., I want to tell my router: > "block any traffic coming in to network A or B through the T1 > interface, if it claims to have originated from network A or B." > > mjr. > We are customer from Network System router because of their filtering capacity. Yes, Marcus you can do what is describe above. You are connected to your T1 via serial 0 you can apply on that interface saying "discard all packets having x.x.*.* source addresses" And of course you don't apply that filter and your ethernet 0 if it's that interface on your network. In the Network System router you have 5 (!) points of filtering : - incoming = all packets getting in your router whatever the interface - input packet on each interface - inside the router ( eg. discard that packet if the next gateway after a look at the routing table is x.x.x.x ) - output packet on each interface - outgoing = all packets getting out of your router whatever the interface And all the packet coming through the router either discarded or not may be copyied to a logging host. Hope this helps 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@GreatCircle.COM Wed Jan 5 14:56:13 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24007; Wed, 5 Jan 94 14:56:13 GMT Received: from ftp.com (babyoil.ftp.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24000; Wed, 5 Jan 94 06:56:06 PST Received: from cucumbers.ftp.com by ftp.com with SMTP id AA27758; Wed, 5 Jan 94 09:56:55 -0500 Message-Id: <9401051456.AA27758@ftp.com> Date: Wed, 05 Jan 1994 09:58:12 EST From: hobbit@ftp.com (*Hobbit*) To: firewalls@greatcircle.com Subject: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I had this exchange with someone recently, after asking him why a machine under his purview was logged sniffing around our networks: ... ============== Date: Tue, 4 Jan 94 16:12:54 -0500 From: mib@gnu.ai.mit.edu (Michael I Bushnell) Subject: Re: mounting.. Date: Tue, 04 Jan 1994 14:25:28 EST From: hobbit@ftp.com (*Hobbit*) au contraire. I believe it is valid to assume that anyone trying to NFS-mount our machines is up to no good. Maybe not your machines, but definitely our machines. Looking for an nfs mount is no more intrusive than looking for an anonymous FTP connection. -mib ============== Now, where do firewallers' opinions tend to align?? _H* From Firewalls-Owner@GreatCircle.COM Wed Jan 5 15:38:08 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24127; Wed, 5 Jan 94 15:38:08 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24120; Wed, 5 Jan 94 07:38:00 PST Received: by relay.tis.com; id AA03855; Wed, 5 Jan 94 10:39:14 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma003849; Wed Jan 5 10:38:45 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA05702; Wed, 5 Jan 94 10:38:39 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA05759; Wed, 5 Jan 94 10:38:38 EST Date: Wed, 5 Jan 94 10:38:38 EST From: mjr@tis.com Message-Id: <9401051538.AA05759@otter.tis.com> To: firewalls@GreatCircle.COM, hobbit@ftp.com Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Looking for an nfs mount is no more intrusive than looking for an >anonymous FTP connection. Opinion: In a sense, by being on the 'net, one is implicitly permitting the world at large to attempt FTP, NFS, SMTP, whatever connections, unless you take active steps to prevent it. I also happen to hold the (not incompatible view) that you are sole lord and master of your internet hookup, and can do anything you like with it, including configuring your router to screen off anyone and anything you don't like. Fact: Whether or not one accepts my assumption that being on the 'net implicitly permits anyone to probe you, and that therefore it's OK -- the fact is, whether it's OK or not, by being on the net, anyone is implicitly enable to probe you. mjr. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 16:09:39 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24253; Wed, 5 Jan 94 16:09:39 GMT Received: from hac2arpa.hac.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24246; Wed, 5 Jan 94 08:09:30 PST Received: from eden.hac.com by hac2arpa.hac.com (4.1/SMI-DDN) id AA00599; Wed, 5 Jan 94 08:10:48 PST Received: from ghost.hac.com by eden.HAC.COM (PMDF #2669 ) id <01H7BEOKJ68W8WW9PE@eden.HAC.COM>; Wed, 5 Jan 1994 08:10:18 PST Received: by ghost.hac.com (4.1/SMI-4.1) id AA02844; Wed, 5 Jan 94 08:10:21 PST Date: 05 Jan 1994 08:10:21 -0800 (PST) From: kemasa@ghost.hac.com (Kemasa) Subject: Re: Opinion requested To: firewalls@GreatCircle.COM, hobbit@ftp.com, mjr@tis.com Message-Id: <9401051610.AA02844@ghost.hac.com> Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From: mjr@tis.com >... >Opinion: > In a sense, by being on the 'net, one is implicitly permitting >the world at large to attempt FTP, NFS, SMTP, whatever connections, >unless you take active steps to prevent it. I also happen to hold >the (not incompatible view) that you are sole lord and master of your >internet hookup, and can do anything you like with it, including >configuring your router to screen off anyone and anything you don't >like. I do not think that you would feel that the same is true in regards to people checking to see if you left any doors or windows unlocked and having them enter if you did (house or car or anything else). It is true that there are anti-social people out there, but I do not think it is acceptable for people to attempt to get into a machine unless they have permission. It is also true that you need to secure a machine as much as possible, unfortunately. I wonder how employers would view such actions from their employees, especially considering the fact that if they permit it they might be liable for any and all damages that occur. >Fact: > Whether or not one accepts my assumption that being on the >'net implicitly permits anyone to probe you, and that therefore it's >OK -- the fact is, whether it's OK or not, by being on the net, >anyone is implicitly enable to probe you. Yes, it is possible, but it should not be considered acceptable behaviour nor should it be tolerated. Care to give your home address so that people can probe your security there? Kemasa. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 16:12:35 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24273; Wed, 5 Jan 94 16:12:35 GMT Received: from almaden.ibm.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24266; Wed, 5 Jan 94 08:12:28 PST Message-Id: <9401051612.AA24266@mycroft.GreatCircle.COM> Received: from ALMVMA by almaden.ibm.com (IBM VM SMTP V2R2) with BSMTP id 9818; Wed, 05 Jan 94 08:13:38 PST Date: Wed, 5 Jan 94 08:13:38 PST From: enge@almaden.ibm.com Apparently-To: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk To: firewalls@greatcircle.com Subject: Re: Opinion requested Reply-To: enge@almaden.ibm.com News-Software: UReply 3.1 References: <9401051538.AA05759@otter.tis.com> How does this analogy sound: Just because my house is on a public street, it doesn't mean you try my windows looking for an open one. In my personal opinion, probing a piece of the network where you aren't invited is certainly bad etiquette. Roy From Firewalls-Owner@GreatCircle.COM Wed Jan 5 16:22:59 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24310; Wed, 5 Jan 94 16:22:59 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24303; Wed, 5 Jan 94 08:22:36 PST Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA10873; Wed, 5 Jan 94 08:23:57 PST Received: from UK.Sun.COM (sunuk) by snail.Sun.COM (4.1/SMI-4.1) id AA00683; Wed, 5 Jan 94 08:23:55 PST Received: from bagsun.UK.Sun.COM by UK.Sun.COM (4.1/SMI-4.1e-UK) id AA14600; Wed, 5 Jan 94 16:23:52 GMT Received: from liberator.UK.Sun.COM (liberator-bb) by bagsun.UK.Sun.COM (4.1/SMI-5.0-sec(uk - sec)) id AA12341; Wed, 5 Jan 94 16:23:53 GMT Received: from uk-usenet.uk.sun.com by liberator.UK.Sun.COM (4.1/SMI-4.0) id AA29177; Wed, 5 Jan 94 16:21:38 GMT Date: Wed, 5 Jan 94 16:21:38 GMT From: Alec.Muffett@UK.Sun.COM (Alec Muffett - Sun IS - System Administrator) Message-Id: <9401051621.AA29177@liberator.UK.Sun.COM> To: firewalls@GreatCircle.COM, hobbit@ftp.com Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>au contraire. I believe it is valid to assume that anyone trying to NFS-mount >>our machines is up to no good. Maybe not your machines, but definitely >>our machines. > >Looking for an nfs mount is no more intrusive than looking for an >anonymous FTP connection. If anyone espoused the latter opinion, in this manner, to *me* - I'd say he has a point, but I'd think him a real *geek*. Such behaviour smacks of rebel adolescent "nosing round" to see what actions you can get away with, without being "found out". "Sure I copied your password file, 'cos it was possible. - but I wasn't going to *DO* anything with it!" ...yeah, right. Might be true, might not. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 16:29:46 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24344; Wed, 5 Jan 94 16:29:46 GMT Received: from erenj.com (ereapp.erenj.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24337; Wed, 5 Jan 94 08:29:34 PST Posted-Date: Wed, 5 Jan 1994 11:30:53 -0500 From: bdboyle@maverick1.erenj.com (Bryan D. Boyle) Message-Id: <9401051130.ZM14457@maverick1.erenj.com> Date: Wed, 5 Jan 1994 11:30:53 -0500 In-Reply-To: hobbit@ftp.com (*Hobbit*) "Opinion requested" (Jan 5, 9:58am) References: <9401051456.AA27758@ftp.com> X-Mailer: Z-Mail (2.1.0 10/1/92) To: firewalls@GreatCircle.COM Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Jan 5, 9:58am, *Hobbit* wrote: > Subject: Opinion requested > I had this exchange with someone recently, after asking him why a machine > under his purview was logged sniffing around our networks: > ... > ============== > Date: Tue, 4 Jan 94 16:12:54 -0500 > From: mib@gnu.ai.mit.edu (Michael I Bushnell) > Subject: Re: mounting.. > > Date: Tue, 04 Jan 1994 14:25:28 EST > From: hobbit@ftp.com (*Hobbit*) > > au contraire. I believe it is valid to assume that anyone trying to NFS-mount > our machines is up to no good. Maybe not your machines, but definitely > our machines. > > Looking for an nfs mount is no more intrusive than looking for an > anonymous FTP connection. > > -mib > ============== > > Now, where do firewallers' opinions tend to align?? > I would tend to align on the side of letting his domain sysadmin know (1st step) of his activities (gotta love that logging...) I would tend to view this as a somewhat obnoxious event, about on par with banging at the firewall to see what ports are available for connection, and then trying them out to see what you can find. IMHO, anonymous FTP is a public *service* you provide so as to limit or control the amount or types of information you make available to the public. It has a clearly-defined directory structure, as well as (or should have) a clearly- defined statement of purpose and controlled contents. Channel-surfing for stray NFS mounts is not the same, unless those nfs mounts are there for public access. NFS is not a common method of access across the net (i don't think...correct me if I am wrong, but I am thinking of this in the same arena as anon/ftp) between non-affiliated organizations. Just because I have data (by definition, as a net/sys admin, I do...) does not mean that I am making it available to you for whatever you want to do with it. As a firewall admin, I have shut down all services I deem as not being germaine to my connection to the world. And, since I decide what services I allow or not, and the user is probing a connection I am responsible for, he/she/it should respect my wishes once they are made known to them. It is not open for debate, especially with some net.critter outside of my jurisdiction. Just my $.02, your mileage may vary. -- Bryan D. Boyle |Physical: ER&E, Rt. 22, Clinton, NJ 08801 #include |Logical: Cogito sum, ergo sum, cogito. (908) 730-3338 |Virtual: bdboyle@erenj.com From Firewalls-Owner@GreatCircle.COM Wed Jan 5 16:43:04 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24445; Wed, 5 Jan 94 16:43:04 GMT Received: from ENH.NIST.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24438; Wed, 5 Jan 94 08:42:54 PST Received: from candela.cfr.nist.gov by ENH.NIST.GOV (PMDF V4.2-13 #4653) id <01H7BM3BKT8G004WY5@ENH.NIST.GOV>; Wed, 5 Jan 1994 11:42:13 EDT Received: by candela.cfr.nist.gov (920330.SGI/911001.SGI) for @enh.nist.gov:firewalls@GreatCircle.COM id AA08742; Wed, 5 Jan 94 11:37:02 -0500 Date: Wed, 05 Jan 1994 11:37:02 -0500 From: wwj@candela.cfr.nist.gov (Walter W. Jones) Subject: response to "opinion requested" To: hobbit@ftp.com, firewalls@GreatCircle.COM Message-Id: <9401051637.AA08742@candela.cfr.nist.gov> Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I would offer the opinion that coincides with the author, namely that looking for an nfs mount is equivalent to looking for an anonymous ftp site. One can exercise similar controls over both. On the social side, however it is not polite simply to try and mount someone's disk, without some notification. Nevertheless, one should be cognizant of the ramifications of an open export. It is much like an unprotected ftp site. You wouldn't leave your car keys unattended in your car, even if you were going to lend your car to someone. And this is not a case of blaming the victim. There are certain obvious precautions one should take in dealing with the world. So far the internet has mostly consisted of cooperative and friendly people. This is changing dramatically. But I do not think it should be viewed pejoratively if someone were to try and do and NFS mount. For example, it could simply be someone who doesn't understand exactly what he is doing. It is still possible to go and hide your head in the sand, but not real productive, I think. Along those lines, I recently tried to ftp to a site which said it was available, and there was code there which I wanted. In this case it was the des code, as discussed in earlier firewall missives. The crucial piece was not available at the foreign site, and there was no anonymous ftp from the originator, although the document claimed there was. That is the other side of this coin, namely one ought to do what one says he will do. I think that being up front with what is available and acceptable and what is not will alleviate much of the irritation associated with stepping on others toes. In this case, mib, or whoever was objecting, had ASSUMED the rules were a particular way, and in fact that is not the case. We should all take this to heart and examine what our systems do and how they interact with the world. I am much more concerned with problems such as discussed in the article by Dan Farmer. There are some very subtle holes which I do not know about, and certainly do not have the time to investigate in excruciating detail. Walter W. Jones, Fire Modeling Group, wwj@nist.gov Building and Fire Research, National Institute of Standards and Technology From Firewalls-Owner@GreatCircle.COM Wed Jan 5 16:46:25 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24465; Wed, 5 Jan 94 16:46:25 GMT Received: from julian.uwo.ca by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24458; Wed, 5 Jan 94 08:46:15 PST Received: from chaplin.csd.uwo.ca by julian.uwo.ca with SMTP id AA22286; Wed, 5 Jan 94 11:47:35 -0500 From: David Wiseman Date: Wed, 5 Jan 94 11:47:32 EST Message-Id: <9401051647.AA00603@no1sun.csd.uwo.ca> To: firewalls@GreatCircle.COM Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> From: enge@almaden.ibm.com >> Date: Wed, 5 Jan 94 08:13:38 PST >> >> How does this analogy sound: >> >> Just because my house is on a public street, it doesn't mean you try >> my windows looking for an open one. >> >> In my personal opinion, probing a piece of the network where you >> aren't invited is certainly bad etiquette. Well... I've heard this analogy a LOT lately and I almost agree with it but in order to add more fuel to the fire, might I point out that if you found yourself in a Shopping Mall during regular hours, you would not consider it improper to try all of the doors looking for an open store... The issue here really seems to be: are computers public or private resources and how does one tell the public from the private? As for me, I don't have an answer to that, but I expect it's going to come down to how good your firewall is. How else does one decide where one is or is not invited? magi From Firewalls-Owner@GreatCircle.COM Wed Jan 5 17:01:39 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24517; Wed, 5 Jan 94 17:01:39 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24510; Wed, 5 Jan 94 09:01:30 PST Received: by relay.tis.com; id AA04830; Wed, 5 Jan 94 12:02:45 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma004828; Wed Jan 5 12:02:43 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA10691; Wed, 5 Jan 94 11:59:37 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA05872; Wed, 5 Jan 94 11:59:36 EST Date: Wed, 5 Jan 94 11:59:36 EST From: mjr@tis.com Message-Id: <9401051659.AA05872@otter.tis.com> To: firewalls@GreatCircle.COM, hobbit@ftp.com, kemasa@ghost.hac.com Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I do not think that you would feel that the same is true in regards to >people checking to see if you left any doors or windows unlocked and >having them enter if you did (house or car or anything else). This is because having my house attached to the ground, and therefore reachable, is not exactly optional. The analogy of house::computer network is a terrible one, and I wish people would stop using it. By default networks are not interconnected. By default houses are connected to streets. If the default was that houses each existed in separate, secure universes, and we had complete control over the size and form of our connection between our homes and the rest of the universe, then the analogy might be a little more sensible. If being connected to the street were optional, how many members of this list would have anything more connected than a single, solid steel front door with an alarm on it? (Maybe a few windows 3 storeys up, with steel grating) >It is >true that there are anti-social people out there, but I do not think >it is acceptable for people to attempt to get into a machine unless >they have permission. Checking for NFS service access does not necessarily imply an attempted breakin. >It is also true that you need to secure a >machine as much as possible, unfortunately. Definitely. Another thing you need to do is decide what constitutes a threat. If you can state, as part of your security analysis, that you've secured a service (let's say, NFS) then it's reasonable to state that someone probing that service is not a threat, or even an attempted break-in. It may indicate they're a bad neighbor, but, just like when you have bad neighbors in the real world, there's not a lot you can *DO* about them unless they are breaking the law by coming onto your property (see below). An example: I run a system that's a major potential target. It's a password-less system, using SecurID for authentication. Therefore, it's not a problem if someone steals the password file from the system. If I got upset every time someone tried to FTP out the password file from its anonymous FTP area, I'd spend 40 hours a week writing irate mail to other systems administrators. It's not worth it. If NFS probes are something you consider a threat, block NFS probes and *THEN* if you get one, you *KNOW* you have a problem. >I wonder how employers would view such actions from their employees, >especially considering the fact that if they permit it they might >be liable for any and all damages that occur. Checking for NFS service access does not necessarily imply an attempted breakin. >Care to give your home address so that people can probe your security >there? 3018 Guilford Ave, Baltimore, MD 21218 BTW, I just bought a new .44mag Desert Eagle, and a wireless burglar alarm system, so if you're inclined to test my security, make sure you have a pretty good bullet proof vest, and pray I don't try for a head shot. mjr. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 09:07:52 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24420; Wed, 5 Jan 94 16:38:16 GMT Received: from ALABAMA.CF.CS.YALE.EDU (RT-GW.CS.YALE.EDU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24413; Wed, 5 Jan 94 08:38:07 PST Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU via SMTP; Wed, 5 Jan 1994 11:39:22 -0500 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.65c/res.client.cf-3.7) id AA18236; Wed, 5 Jan 1994 11:39:21 -0500 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199401051639.AA18236@SPARKY.CF.CS.YALE.EDU> To: firewalls@greatcircle.com Cc: enge@almaden.ibm.com In-Reply-To: Your message of Wed, 05 Jan 94 08:13:38 PST. Date: Wed, 05 Jan 94 11:39:20 -0500 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >How does this analogy sound: > > Just because my house is on a public street, it doesn't mean you try > my windows looking for an open one. Hmmmm. How about : Your house is on a public street, a light is on in a room in your house where the shades/blinds are not obscuring the window and I am looking in from the street or sidewalk?? Probing is probably a bit more active than the above analogy. Having a light on inside with the shades not drawn is somewhat exhibitionistic (analogous to proving public services such as anonymous ftp, gopher, WWW/HTTP, etc.). For probing TCP ports other than 20,21,23,25,70,80,119 or UDP ports other than FSP's (ie TFTP's) I'd add the following modification to the above real-life scenario : The inside of your house is dark and I am shining a powerful flashlight, search or camcorder light into your window. I wouldn't consider an exploratory finger, ping, spray or 'VRFY/EXPN' on the SMTP port as invasive unless someone is using them to harass a machine with a denial of service type attack.. Someone trying to login via telnet/rlogin as guest, demo, etc is questionable, trying to login as root,daemon,bin,adm is not. - Morrow From Firewalls-Owner@GreatCircle.COM Wed Jan 5 17:09:46 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24593; Wed, 5 Jan 94 17:09:46 GMT Received: from firewall.mc.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24586; Wed, 5 Jan 94 09:09:36 PST Received: from jericho.mc.com by firewall.mc.com with SMTP id AA12655 (5.65c/IDA-1.4.4 for ); Wed, 5 Jan 1994 12:11:00 -0500 Received: from darkstar by jericho.mc.com (4.1/1.34/indent-1.0 for mc.com) id AA18615; Wed, 5 Jan 94 12:10:59 EST From: blu@jericho.mc.com (Brian Utterback) Received: by darkstar (4.1//ident-1.0) id AA18094; Wed, 5 Jan 94 12:10:58 EST Date: Wed, 5 Jan 94 12:10:58 EST Message-Id: <9401051710.AA18094@darkstar> To: firewalls@greatcircle.com Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Now this is a toughy. The answer is "depends". Kind of like checking a doorknob, opening the door and walking in. If it is the door to my store, fine; if it is the door to my house, no way. Some archives offer filesystems to NFS just like they offer FTP. So someone looking for an NFS filesystem could just be looking for a public archive. I think however, that NFS is a little more intrusive than FTP. Public NFS systems are pretty rare, I think, so I might find it anti-social unless invited. For an analogy, I would think of NFS as always being on a home. You would not walk in unless you had an invite that said that there was an Open House Party at that address. 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 You can't grep dead trees. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 17:15:57 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24619; Wed, 5 Jan 94 17:15:57 GMT Received: from ees1a0.engr.ccny.cuny.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24612; Wed, 5 Jan 94 09:15:48 PST Received: by ees1a0.engr.ccny.cuny.edu (4.1/SMI-4.1) id AA02646; Wed, 5 Jan 94 12:00:14 EST Date: Wed, 5 Jan 1994 11:49:04 -0500 (EST) From: Dan Schlitt Subject: Re: Opinion requested To: mjr@tis.com Cc: firewalls@GreatCircle.COM, hobbit@ftp.com In-Reply-To: <9401051538.AA05759@otter.tis.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Since you ask for opinions I will give you mine. There are two parts to the situation. On the systems that you control it is as mjr says. I is your responsibility to protect you hosts to the extent that you feel is required. In my case that includes restricting nfs mounts to hosts that are on the local network. And not even permitting all of them to mount anything they want. The second part relates to the systems which were probing. If I got a report that someone here was doing such probing I would have a "friendly" talk with them telling them that what they were doing was "not nice" and to quit it. At LISA there was a discussion of things that you would require users of your systems to agree to. One such was that the appearance of attempting to break in to a system was an offense which could lead to loss of priviledges. I believe that that requirement is something that I need to impose in the interest of a more secure Internet. I would include any extensive probing for nfs mounts on systems, either here on campus or elsewhere, something that had the appearance of a breakin attempt. /dan Dan Schlitt School of Engineering Computer Systems dan@ee-mail.engr.ccny.cuny.edu City College of New York (212)650-6760 New York, NY 10031 From Firewalls-Owner@GreatCircle.COM Wed Jan 5 17:18:02 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24637; Wed, 5 Jan 94 17:18:02 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24630; Wed, 5 Jan 94 09:17:55 PST Message-Id: <9401051717.AA24630@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Wed Jan 5 12:18:17 EST 1994 To: bdboyle@maverick1.erenj.com (Bryan D. Boyle) Cc: firewalls@GreatCircle.COM Subject: Re: Opinion requested Date: Wed, 05 Jan 94 12:18:15 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Channel-surfing for stray NFS mounts is not the same, unless those nfs mounts are there for public access. NFS is not a common method of access across the net (i don't think... correct me if I am wrong, but I am thinking of this in the same arena as anon/ftp) between non-affiliated organizations. This, I think, is the key point: to what extent is external NFS a common service on the Internet? To the extent that it is common, a query to see if you offer that service is reasonable (but see below); conversely, if the service is rare, a polite Internet user should not essay its use without a good reason for thinking that the target site offers external NFS. The difference between FTP and TFTP is instructive. The former is a common service, and attempts to fire up anonymous ftp are, in general, reasonable (though that may change in the future, as more and more sites adopt the ftp.foo.bar naming convention). TFTP, while frequently available, is very rarely intended for external use, so I classify any TFTP probe as probably hostile. The problem here is that NFS is a very insecure protocol, and there are many instances of attacks via that route. As I noted in my ``There Be Dragons'' paper, it is now impossible to distinguish between a clever attacker and a sophisticated user. The AMD automounter makes things worse, since it incorporates support for clients that wish to do anonymous mounts. The best I can do is to look for characteristic profiles of legitimate use -- but an attacker can mimic those, too. In short -- I'll follow up on attempts to invoke our (non-existent) NFS daemon. (Btw, those are rather rare, though we've had a few -- which may say something about the expectations of most users.) But I won't ring loud alarms without further evidence. --Steve Bellovin From Firewalls-Owner@GreatCircle.COM Wed Jan 5 17:49:18 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24711; Wed, 5 Jan 94 17:49:18 GMT Received: from london.micrognosis.com (midas.london.micrognosis.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24704; Wed, 5 Jan 94 09:49:03 PST Received: by london.micrognosis.com (4.1/NAR-Gateway) id AA04705; Wed, 5 Jan 94 17:50:04 GMT Received: from zeus.london.micrognosis.com(192.83.165.17) by midas via smap (V1.0mjr) id sma004703; Wed Jan 5 17:49:49 1994 Received: from moria by zeus.london.micrognosis.com (4.1/SMI-4.1) id AA14425; Wed, 5 Jan 94 17:49:46 GMT From: nreadwin@london.micrognosis.com (Neil Readwin) Received: by moria (4.1//ident-1.0) id AA07983; Wed, 5 Jan 94 17:49:45 GMT Message-Id: <9401051749.AA07983@moria> Subject: Re: Opinion requested To: hobbit@ftp.com (*Hobbit*) Date: Wed, 5 Jan 1994 17:49:45 +0000 (GMT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9401051456.AA27758@ftp.com> from "*Hobbit*" at Jan 5, 94 09:58:12 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 327 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Looking for an nfs mount is no more intrusive than looking for an > anonymous FTP connection. Am I to assume that probing random machines for anonymous FTP accounts is considered acceptable? Neil -- Phone: +44 71 815 5283 E-mail: nreadwin@micrognosis.co.uk Anything is a cause for sorrow that my mind or body has made From Firewalls-Owner@GreatCircle.COM Wed Jan 5 18:00:28 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24832; Wed, 5 Jan 94 18:00:28 GMT Received: from clavin.uprc.com (uprc.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24822; Wed, 5 Jan 94 10:00:15 PST Received: from cygnus.uprc.com by clavin.uprc.com (4.1/3.2.012693-Union Pacific Resources Company); id AA06317 for firewalls@GreatCircle.COM; Wed, 5 Jan 94 12:00:33 CST Received: by cygnus.uprc.com (5.0/SMI-SVR4) id AA29382; Wed, 5 Jan 1994 12:00:55 +0600 Date: Wed, 5 Jan 1994 12:00:55 +0600 From: lacoursj@uprc.com (Jeffrey D. LaCoursiere) Message-Id: <9401051800.AA29382@cygnus.uprc.com> To: firewalls@GreatCircle.COM, hobbit@ftp.com, mjr@tis.com, kemasa@ghost.hac.com Subject: Re: Opinion requested X-Sun-Charset: US-ASCII Content-Length: 2176 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > >Opinion: > > In a sense, by being on the 'net, one is implicitly permitting > >the world at large to attempt FTP, NFS, SMTP, whatever connections, > >unless you take active steps to prevent it. I also happen to hold > >the (not incompatible view) that you are sole lord and master of your > >internet hookup, and can do anything you like with it, including > >configuring your router to screen off anyone and anything you don't > >like. > > I do not think that you would feel that the same is true in regards to > people checking to see if you left any doors or windows unlocked and > having them enter if you did (house or car or anything else). It is > true that there are anti-social people out there, but I do not think > it is acceptable for people to attempt to get into a machine unless > they have permission. It is also true that you need to secure a > machine as much as possible, unfortunately. > > I wonder how employers would view such actions from their employees, > especially considering the fact that if they permit it they might > be liable for any and all damages that occur. > > >Fact: > > Whether or not one accepts my assumption that being on the > >'net implicitly permits anyone to probe you, and that therefore it's > >OK -- the fact is, whether it's OK or not, by being on the net, > >anyone is implicitly enable to probe you. > > Yes, it is possible, but it should not be considered acceptable > behaviour nor should it be tolerated. > > Care to give your home address so that people can probe your security > there? > > > > Kemasa. > This all comes down to "computer ethics" in which many things are possible, but not ethical. Although it is possible to cd into the mail spool directory and delete people's mail files, it is an unethical thing to do. The car/house analogy was a good one except that breaking into a car/house is considered illegal, whereas mounting an NFS filesystem from a machine that gladly exports it is not (yet, anyway!). Do any real laws apply here? I would definately stamp the act "unethical", but that and 50 cents would buy a cup of coffee... Jeff LaCoursiere Network Admin UPRC Ft. Worth, TX From Firewalls-Owner@GreatCircle.COM Wed Jan 5 18:39:53 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25002; Wed, 5 Jan 94 18:39:53 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24995; Wed, 5 Jan 94 10:39:45 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05510; Wed, 5 Jan 94 13:41:10 -0500 Received: from rayssd.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 133933.11439; Wed, 5 Jan 1994 13:39:33 EST Received: from sccux1.msd.ray.com by rayssd.ssd.ray.com with SMTP id AA27887 (5.65c/IDA-1.5 for ); Wed, 5 Jan 1994 13:06:05 -0500 Received: by sccux1.msd.ray.com (5.57/Ultrix3.0-C) id AA11632; Wed, 5 Jan 94 13:09:28 -0500 Date: Wed, 5 Jan 94 13:09:28 -0500 From: "Bill Gianopoulos" Message-Id: <9401051809.AA11632@sccux1.msd.ray.com> To: firewalls@greatcircle.com Subject: Dummy Idnet server Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A couple of months ago, there was some discussion on this list about what a firewall machine should do in response to an "ident" query. The responses indicated that it must not block the port completely, as this would cause anyone who was doing a legitimate ident query (which evidently includes newer versions of sendmail) to delay for some timeout period before doing their thing. Someone posted a dummy ident server which always returned a userid of "firewall" (or something like that). Somone else indicated that this was NOT the correct way to handle this, and what should really be done, according to the RFC was to return the HIDDEN-USER error. Upon reading the RFC myself, I reached the same conclusion and modified this dummy server to return the HIDDEN-USER error. It occured to me, however, that there are problems with this approach as well. If someone spoofing my IP address tries to break into another system, and that system somehow (probably due to the spoofer not being as clever as he might be) actually makes it back to my server with an ident query, I would like to return the correct "NO-USER" error condition (indicating this connection did NOT come from me) rather than the incorrect "HIDDEN-USER" error condition (indicating this connection did come from me, but I am not going to tell you the user name). I think the return of the correct error condition would put us on much better legal standing if the site being broken into tried to take legal action. I think the real correct way to solve this is to modify the real ident server so that it can be invoked with a "-hide" option (or something simillar) to cause the HIDDEN-USER error to be generated in only those cases where it would normally return a USERID, but to work normally in all other respects. So, my question is, does anyone know of a public domain ident server which would work under Ultrix 4.3 for which I could obtain source? ------------------------ Bill Gianopoulos Raytheon Company voice: 617-274-3221 email: u84718@sccux1.msd.ray.com From Firewalls-Owner@GreatCircle.COM Wed Jan 5 18:50:49 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25076; Wed, 5 Jan 94 18:50:49 GMT Received: from ees1a0.engr.ccny.cuny.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25068; Wed, 5 Jan 94 10:50:38 PST Received: by ees1a0.engr.ccny.cuny.edu (4.1/SMI-4.1) id AA04592; Wed, 5 Jan 94 13:50:35 EST Date: Wed, 5 Jan 1994 13:46:15 -0500 (EST) From: Dan Schlitt Subject: Re: Opinion requested To: Neil Readwin Cc: *Hobbit* , firewalls@GreatCircle.COM In-Reply-To: <9401051749.AA07983@moria> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk With the advent of archie there really is no need for random probing. If people don't want their ftp-able stuff in archie that should be taken as a sign that their anonymous ftp is not intended for general use. The excuse that "I was just looking for a source of xxxx" doesn't cut it any more. /dan Dan Schlitt School of Engineering Computer Systems dan@ee-mail.engr.ccny.cuny.edu City College of New York (212)650-6760 New York, NY 10031 On Wed, 5 Jan 1994, Neil Readwin wrote: > > Looking for an nfs mount is no more intrusive than looking for an > > anonymous FTP connection. > > Am I to assume that probing random machines for anonymous FTP accounts is > considered acceptable? Neil > -- > Phone: +44 71 815 5283 E-mail: nreadwin@micrognosis.co.uk > Anything is a cause for sorrow that my mind or body has made From Firewalls-Owner@GreatCircle.COM Wed Jan 5 18:52:50 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25100; Wed, 5 Jan 94 18:52:50 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25093; Wed, 5 Jan 94 10:52:42 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11149; Wed, 5 Jan 94 13:54:07 -0500 Received: from megatek.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 135210.12377; Wed, 5 Jan 1994 13:52:10 EST Received: from ninja.megatek by megatek.com (4.1/smail2.5/09-29-87) id AA17356; Wed, 5 Jan 94 10:50:05 PST Received: by ninja.megatek (4.1/SMI-4.1) id AA25299; Wed, 5 Jan 94 10:50:02 PST Date: Wed, 5 Jan 94 10:50:02 PST From: randy@megatek.com (Randy Davis) Message-Id: <9401051850.AA25299@ninja.megatek> To: Firewalls@GreatCircle.COM Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk kemasa@ghost.hac.com wrote: |>From: mjr@tis.com |>Fact: |> Whether or not one accepts my assumption that being on the |>'net implicitly permits anyone to probe you, and that therefore it's |>OK -- the fact is, whether it's OK or not, by being on the net, |>anyone is implicitly enable to probe you. | |Yes, it is possible, but it should not be considered acceptable |behaviour nor should it be tolerated. Reality check time... Just what do you propose to *do* if someone "checks the locks on your windows"? If they have their own internet site and have done no damage to your site in any provable way, then I'd say you are out of luck. Whining that it "should not be considered acceptable behaviour nor should it be tolerated" is basically useless and worse, unenforcable. It *should* be assumed that someone is going to try your locks; ignoring the fact is simply burying your head in the sand and hoping it won't happen. With that said, I also will follow-up attempts to get into my firewall from the outside, and have mailed a number of "desist" messages to users and their administrators. However, I think we all agree that "security through obscurity" is just a stupid hope that no one will try your unlocked door... |Care to give your home address so that people can probe your security |there? The two aren't that analogous. Nice try, though. Randy Davis Email: randy@megatek.com Corporate Network and System Administrator megatek!randy@uunet.uu.net Megatek Corporation, San Diego, California ucsd!megatek!randy From Firewalls-Owner@GreatCircle.COM Wed Jan 5 18:56:29 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25137; Wed, 5 Jan 94 18:56:29 GMT Received: from ENH.NIST.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25130; Wed, 5 Jan 94 10:56:12 PST Received: from candela.cfr.nist.gov by ENH.NIST.GOV (PMDF V4.2-13 #4653) id <01H7BQSEQWVK004DGS@ENH.NIST.GOV>; Wed, 5 Jan 1994 13:56:58 EDT Received: by candela.cfr.nist.gov (920330.SGI/911001.SGI) for @enh.nist.gov:hobbit@ftp.com id AA09379; Wed, 5 Jan 94 13:51:59 -0500 Date: Wed, 05 Jan 1994 13:51:59 -0500 From: wwj@candela.cfr.nist.gov (Walter W. Jones) Subject: Re: Opinion requested To: nreadwin@london.micrognosis.com (Neil Readwin), hobbit@ftp.com (*Hobbit*) Cc: firewalls@GreatCircle.COM Message-Id: <9401051851.AA09379@candela.cfr.nist.gov> Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>From Firewalls-Owner@GreatCircle.COM Wed Jan 5 13:42:23 1994 >>Received: from relay1.UU.NET by candela.cfr.nist.gov via SMTP (920330.SGI/911001.SGI) >> for wwj id AA09371; Wed, 5 Jan 94 13:42:23 -0500 >>Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP >> (5.61/UUNET-internet-primary) id AA09552; Wed, 5 Jan 94 13:35:02 -0500 >>Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) >> id AA24711; Wed, 5 Jan 94 17:49:18 GMT >>Received: from london.micrognosis.com (midas.london.micrognosis.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) >> id AA24704; Wed, 5 Jan 94 09:49:03 PST >>Received: by london.micrognosis.com (4.1/NAR-Gateway) >> id AA04705; Wed, 5 Jan 94 17:50:04 GMT >>Received: from zeus.london.micrognosis.com(192.83.165.17) by midas via smap (V1.0mjr) >> id sma004703; Wed Jan 5 17:49:49 1994 >>Received: from moria by zeus.london.micrognosis.com (4.1/SMI-4.1) >> id AA14425; Wed, 5 Jan 94 17:49:46 GMT >>From: nreadwin@london.micrognosis.com (Neil Readwin) >>Received: by moria >> (4.1//ident-1.0) id AA07983; Wed, 5 Jan 94 17:49:45 GMT >>Message-Id: <9401051749.AA07983@moria> >>Subject: Re: Opinion requested >>To: hobbit@ftp.com (*Hobbit*) >>Date: Wed, 5 Jan 1994 17:49:45 +0000 (GMT) >>Cc: firewalls@GreatCircle.COM >>In-Reply-To: <9401051456.AA27758@ftp.com> from "*Hobbit*" at Jan 5, 94 09:58:12 am >>X-Mailer: ELM [version 2.4 PL23] >>Content-Type: text >>Content-Length: 327 >>Sender: Firewalls-Owner@GreatCircle.COM >>Precedence: bulk >> >>> Looking for an nfs mount is no more intrusive than looking for an >>> anonymous FTP connection. >> >>Am I to assume that probing random machines for anonymous FTP accounts is >>considered acceptable? Neil >>-- >> Phone: +44 71 815 5283 E-mail: nreadwin@micrognosis.co.uk >> Anything is a cause for sorrow that my mind or body has made >> Not only does the world consider it acceptable, but the behavior is encouraged in MANY books which have been published about the internet. It is certainly the modus operandus of both gopher and mosaic, and so forth. People do not come into world knowing right from wrong. They need to be taught. It must be done in a way that educates and sensitizes without being pejorative. For example, there are guidelines worked out for USENET (how many of these new people know about USENET?) and what the proper ettiquette is for joining in. Walter W. Jones, Fire Modeling Group, wwj@nist.gov Building and Fire Research, National Institute of Standards and Technology From Firewalls-Owner@GreatCircle.COM Wed Jan 5 19:10:01 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25239; Wed, 5 Jan 94 19:10:01 GMT Received: from rip.psg.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25232; Wed, 5 Jan 94 11:09:49 PST Received: by rip.psg.com (Smail3.1.28.1 #6) id m0pHddK-00035cC; Wed, 5 Jan 94 11:11 PST Message-Id: From: randy@psg.com (Randy Bush) Subject: Re: Opinion requested To: randy@megatek.com (Randy Davis) Date: Wed, 5 Jan 1994 11:11:05 -0800 (PST) Cc: Firewalls@GreatCircle.COM In-Reply-To: <9401051850.AA25299@ninja.megatek> from "Randy Davis" at Jan 5, 94 10:50:02 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 165 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Just what do you propose to *do* if someone "checks the locks on your > windows"? Call the police and report trespassing and attempted breaking and entering. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 19:13:08 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25264; Wed, 5 Jan 94 19:13:08 GMT Received: from lns62.lns.cornell.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25257; Wed, 5 Jan 94 11:12:57 PST Received: from LNS62.LNS.CORNELL.EDU by LNS62.LNS.CORNELL.EDU (PMDF V4.2-13 #3448) id <01H7BRFO9N6O8WXW9M@LNS62.LNS.CORNELL.EDU>; Wed, 5 Jan 1994 14:15:43 EST Date: Wed, 05 Jan 1994 14:15:43 -0500 (EST) From: "Selden E. Ball, Jr." Subject: Re: Opinion requested To: randy@megatek.com, Firewalls@GreatCircle.COM Message-Id: <01H7BRFOB92A8WXW9M@LNS62.LNS.CORNELL.EDU> X-Vms-To: IN%"randy@megatek.com",IN%"Firewalls@GreatCircle.COM" X-Vms-Cc: SEB Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Randy Davis posted > Just what do you propose to *do* if someone "checks the locks on your >windows"? If they have their own internet site and have done no damage to >your site in any provable way, then I'd say you are out of luck. Whining >that it "should not be considered acceptable behaviour nor should it be >tolerated" is basically useless and worse, unenforcable. A prudent network administrator of a probed site should notify the administrator responsible for the system where the probe initiated. It is then up to the remote administrator to take approprate action. Most such cases turn out to be "innocent," but if a person is not informed that such activity is inappropriate, that person will never learn better. Unfortunately, probing for anonymous ftp accounts is also done by those who are seeking sites for distributing illegally cracked software and other antisocial publications. Selden ------ Selden E. Ball, Jr. Cornell University Voice: +1-607-255-0688 Laboratory of Nuclear Studies FAX: +1-607-255-8062 230A Wilson Synchrotron Lab BITNET: SEB@CRNLNS Judd Falls & Dryden Road Internet: SEB@LNS61.TN.CORNELL.EDU Ithaca, NY, USA 14853-8001 HEPnet/SPAN: LNS61::SEB = 44283::SEB From Firewalls-Owner@GreatCircle.COM Wed Jan 5 19:25:16 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25345; Wed, 5 Jan 94 19:25:16 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25338; Wed, 5 Jan 94 11:25:09 PST Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA17266; Wed, 5 Jan 94 14:26:33 -0500 Date: Wed, 5 Jan 94 14:26:33 -0500 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9401051926.AA17266@bedrock.cs.UMD.EDU> To: mjr@tis.com Subject: Re: Opinion requested Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > See my response to the mailing list. :) > [...entering yard is not a security event ; ...entering house is...] Marcus, Well, I've been waiting for your response to the mailing list to percolate its way into my mailbox ; can't stand it any longer ;). I'd wager that if someone walked into your yard and stood next to a window ( instead of the front door ) you'd consider it a security event. Street->yard->house(->living-room?->bedroom?) is perhaps an inappropriate way to think of all this. I'm not saying I know what *is* an appropriate way; perhaps street->building->condo -- where the "building" is the common environment provided by the connection service provider to all clients. I'll go ahead and post this to firewalls, and conduct the rest of our conversation in public. Regards, Richard From Firewalls-Owner@GreatCircle.COM Wed Jan 5 11:49:01 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24870; Wed, 5 Jan 94 18:06:03 GMT Received: from BGUVM.BGU.AC.IL by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24857; Wed, 5 Jan 94 10:05:10 PST Received: from ramon.bgu.ac.il by BGUVM.BGU.AC.IL (IBM VM SMTP V2R2) with TCP; Wed, 05 Jan 94 20:06:43 IST Received: by ramon.bgu.ac.il (920330.SGI/920502.SGI.AUTO) for @bguvm.bgu.ac.il:firewalls@greatcircle.com id AA09490; Wed, 5 Jan 94 20:02:32 +0200 From: jsz@ramon.bgu.ac.il Message-Id: <9401051802.AA09490@ramon.bgu.ac.il> Subject: Re: Opinion requested To: hobbit@ftp.com (*Hobbit*), firewalls@greatcircle.com Date: Wed, 5 Jan 94 20:02:25 IST In-Reply-To: <9401051456.AA27758@ftp.com>; from "*Hobbit*" at Jan 5, 94 9:58 am Origanization: The Society for the Propagation of Healthy Sex & Prevention of Pervertness X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk *Hobbit* has said > > ============== > Date: Tue, 4 Jan 94 16:12:54 -0500 > From: mib@gnu.ai.mit.edu (Michael I Bushnell) > Subject: Re: mounting.. > > Date: Tue, 04 Jan 1994 14:25:28 EST > From: hobbit@ftp.com (*Hobbit*) > > au contraire. I believe it is valid to assume that anyone trying to NFS-mount > our machines is up to no good. Maybe not your machines, but definitely > our machines. > > Looking for an nfs mount is no more intrusive than looking for an > anonymous FTP connection. > > -mib > ============== > > Now, where do firewallers' opinions tend to align?? > Apparently you seem to be unaware with general attitude of FSF [Free Software Foundation] of MIT towards security. [gnu.ai.mit.edu domain belongs to FSF] Probably this little piece of an /etc/motd file from spiff.gnu.ai.mit.edu, on which I have happened to have a guest account. ------- Please note there is no guarantee of privacy on these machines (for email, files, or even network activity). We do not wish to enforce the level of security that would be necessary to insure such privacy. If you don't know why we don't like security, ask REQUEST@GNU.AI.MIT.EDU ------ --- Jonathan From Firewalls-Owner@GreatCircle.COM Wed Jan 5 11:50:36 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25328; Wed, 5 Jan 94 19:21:53 GMT Received: from remarque.berkeley.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25321; Wed, 5 Jan 94 11:21:45 PST Received: from localhost by remarque.berkeley.edu (8.6.4/1.31) id LAA12933; Wed, 5 Jan 1994 11:19:30 -0800 Date: Wed, 5 Jan 1994 11:19:30 -0800 From: richardt@remarque.berkeley.edu (Richard Threadgill) Message-Id: <199401051919.LAA12933@remarque.berkeley.edu> Subject: FYI anonymous NFS Apparently-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have had HP support people recommend that I "just anonymously nfs-mount foo.hp.com" to get patches, etc from them. While it is distressing, there are at least some small group of people inadvertently teaching naive users and admins that anonymous nfs over long-haul links is a routine way to supply access to public data. Blech. RichardT From Firewalls-Owner@GreatCircle.COM Wed Jan 5 11:53:40 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25198; Wed, 5 Jan 94 19:04:07 GMT Received: from vaxb.acs.uwlax.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25181; Wed, 5 Jan 94 11:03:51 PST Received: from VMSmail by vaxb.acs.uwlax.edu; Wed, 5 Jan 94 13:04 CDT Message-Id: <24010513045129@vaxb.acs.uwlax.edu> Date: Wed, 5 Jan 94 13:04 CDT From: "Michael Nittmann, The Trane Company?" Subject: Re: opinion requested/probing To: firewalls@greatcircle.com X-Vms-To: IN%"firewalls@greatcircle.com" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk there is the need of testing connectivity to be balanced against the need of protected privacy. I would not compare the situation to the house/backdoor thing since there the legal situation is clear (who opens my backdoor gets shot right in the doorway). I agree to tolerate pings to my public interfaces, or publicly accessible dns servers, or to send mail to test tcp/ip connectivity. However, who tries 6000 ranges, 59xx ranges, 2000s, 3000s gets logged. ... and who lets NFS through a public interface needs to be punished severely. there is the point of willful insecure environments (nfs via Internet is one of them) which I would treat the same way as somebody letting an unlocked car with the ignition key inside on a Manhattan side street: if you give it away then there is no crime and you are not entitled to insurance coverage. But: whoever sends me an email trying to knock at sendmail bugs, whoever tries to log in to a vax with a >128 byte password, and all the other known things (see above), clearly shows criminal intent and should get shot right in the doorway. Since there are public telnet and ftp sites, I see no reason to use a network target with which I do not do business, to test connectivity or efficiency of filters. I focus on pragmatic protection vs. endless ethical discussions that anyways only apply to straight people. The bad guys will not care, and anyways they will always have guns, so outlawing of practices won't help. Mike (mho) From Firewalls-Owner@GreatCircle.COM Wed Jan 5 11:55:15 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25058; Wed, 5 Jan 94 18:47:00 GMT Received: from large.cisco.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25051; Wed, 5 Jan 94 10:46:50 PST Received: from localhost by large.cisco.com with SMTP id AA26597 (5.67a/IDA-1.5 for ); Wed, 5 Jan 1994 10:48:04 -0800 Message-Id: <199401051848.AA26597@large.cisco.com> To: kemasa@ghost.hac.com (Kemasa) Cc: firewalls@GreatCircle.COM, hobbit@ftp.com, mjr@tis.com Subject: Re: Opinion requested In-Reply-To: Your message of "05 Jan 1994 08:10:21 PST." <9401051610.AA02844@ghost.hac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 05 Jan 1994 10:48:04 -0800 From: David Carrel Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Kemasa, I think it wrong to assume that an information network can be described with analogies to a personal residence. > I do not think that you would feel that the same is true in regards to > people checking to see if you left any doors or windows unlocked and > having them enter if you did (house or car or anything else). It is > true that there are anti-social people out there, but I do not think > it is acceptable for people to attempt to get into a machine unless > they have permission. It is also true that you need to secure a > machine as much as possible, unfortunately. Maybe a better analogy is to a downtown shopping district. I don't wait for an invitation to enter a store, I try the door and walk in. If the door is locked, then I won't break it down, but if it's unlocked, I go right in. I guess the biggest point that I am trying to make here is that we can't keep trying to describe our networks in terms of suburban tree lined neighborhoods. They're just different beasts. Networks are used for the exchange of information. Most of the information that I get off the net, I have to go out and find. No one sends me a personal invitation. The only way that information access can scale on the "Information Highway" is to assume permission until you are denied. This is also the only RESPONSIBLE way for a security administrator to look at their own site. If I can NFS mount your filesystem, then I consider that you have decided that it is public. With global filesystems like AFS (DFS) we are moving towards a point where the path to your systems is clearly marked, and everything is visible (read: public) until you determine that you want some subset of your tree to be private. X.500 is annother great example of a mix of public and private information where the onus is on you to make the determination as to what you want me to be able to access. If you leave it up to me, then YOU are being irresponsible, not me. ---------------------------------------------------------------------------- David Carrel | E-mail: carrel@cisco.com Security Development, Cisco Systems | phone: (415) 324-5207 P.O. Box 3075, 1525 O'Brien Dr. | fax: (415) 903-7111 Menlo Park, Ca, 94025-1435 | These words are mine, not Cisco's ---------------------------------------------------------------------------- From Firewalls-Owner@GreatCircle.COM Wed Jan 5 12:41:11 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25050; Wed, 5 Jan 94 18:46:37 GMT Received: from ENH.NIST.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25043; Wed, 5 Jan 94 10:46:25 PST Received: from candela.cfr.nist.gov by ENH.NIST.GOV (PMDF V4.2-13 #4653) id <01H7BQGLUDQ80053CF@ENH.NIST.GOV>; Wed, 5 Jan 1994 13:47:28 EDT Received: by candela.cfr.nist.gov (920330.SGI/911001.SGI) for @enh.nist.gov:firewalls@GreatCircle.COM id AA09329; Wed, 5 Jan 94 13:42:17 -0500 Date: Wed, 05 Jan 1994 13:42:17 -0500 From: wwj@candela.cfr.nist.gov (Walter W. Jones) Subject: Re: Opinion requested To: Alec.Muffett@UK.Sun.COM (Alec Muffett - Sun IS - System Administrator), hobbit@ftp.com, firewalls@GreatCircle.COM Message-Id: <9401051842.AA09329@candela.cfr.nist.gov> Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>From Firewalls-Owner@GreatCircle.COM Wed Jan 5 13:17:36 1994 >>Received: from relay1.UU.NET by candela.cfr.nist.gov via SMTP (920330.SGI/911001.SGI) >> for wwj id AA09191; Wed, 5 Jan 94 13:17:36 -0500 >>Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP >> (5.61/UUNET-internet-primary) id AA19747; Wed, 5 Jan 94 12:52:45 -0500 >>Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) >> id AA24310; Wed, 5 Jan 94 16:22:59 GMT >>Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) >> id AA24303; Wed, 5 Jan 94 08:22:36 PST >>Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) >> id AA10873; Wed, 5 Jan 94 08:23:57 PST >>Received: from UK.Sun.COM (sunuk) by snail.Sun.COM (4.1/SMI-4.1) >> id AA00683; Wed, 5 Jan 94 08:23:55 PST >>Received: from bagsun.UK.Sun.COM by UK.Sun.COM (4.1/SMI-4.1e-UK) >> id AA14600; Wed, 5 Jan 94 16:23:52 GMT >>Received: from liberator.UK.Sun.COM (liberator-bb) by bagsun.UK.Sun.COM (4.1/SMI-5.0-sec(uk - sec)) >> id AA12341; Wed, 5 Jan 94 16:23:53 GMT >>Received: from uk-usenet.uk.sun.com by liberator.UK.Sun.COM (4.1/SMI-4.0) >> id AA29177; Wed, 5 Jan 94 16:21:38 GMT >>Date: Wed, 5 Jan 94 16:21:38 GMT >>From: Alec.Muffett@UK.Sun.COM (Alec Muffett - Sun IS - System Administrator) >>Message-Id: <9401051621.AA29177@liberator.UK.Sun.COM> >>To: firewalls@GreatCircle.COM, hobbit@ftp.com >>Subject: Re: Opinion requested >>Sender: Firewalls-Owner@GreatCircle.COM >>Precedence: bulk >> >> >>au contraire. I believe it is valid to assume that anyone trying to NFS-mount >> >>our machines is up to no good. Maybe not your machines, but definitely >> >>our machines. >> > >> >Looking for an nfs mount is no more intrusive than looking for an >> >anonymous FTP connection. >> >>If anyone espoused the latter opinion, in this manner, to *me* - I'd >>say he has a point, but I'd think him a real *geek*. >> >>Such behaviour smacks of rebel adolescent "nosing round" to see what >>actions you can get away with, without being "found out". >> >>"Sure I copied your password file, 'cos it was possible. >> - but I wasn't going to *DO* anything with it!" >> >>...yeah, right. Might be true, might not. >> Why does anyone expect people to behave differently on the internet than in society in general? Walter W. Jones, Fire Modeling Group, wwj@nist.gov Building and Fire Research, National Institute of Standards and Technology From Firewalls-Owner@GreatCircle.COM Wed Jan 5 20:57:04 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25774; Wed, 5 Jan 94 20:57:04 GMT Received: from mordor.cs.du.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25767; Wed, 5 Jan 94 12:56:50 PST Received: from nyx10.cs.du.edu by mordor.cs.du.edu with SMTP id AA02518 (5.65c/IDA-1.4.4 for ); Wed, 5 Jan 1994 13:56:45 -0700 Received: by nyx10.cs.du.edu (4.1/SMI-4.1) id AA24657; Wed, 5 Jan 94 13:57:26 MST From: mlindsey@nyx10.cs.du.edu (Mark R. Lindsey) Date: Wed, 5 Jan 1994 13:57:26 -0700 X-Disclaimer: Why would Denver U agree with me? Hmmmmm? X-Gates: Bill is a moral force, a spectral force, a force that shapes, a force that molds. A force with thick, thick glasses. Message-Id: X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: firewalls@greatcircle.com Subject: mother may I ftp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk When I first got into the ``open computering'' scene (I'm still a little uncomfortable with the term), I was of the basic opinion that it's up to the users and administrators of systems to secure their own stuff. Example: If you wanna have files on a unix system, learn to use chmod or it's on your head. Another example: If you wanna listen for logins, eliminate `guest' and `anonymous' or it's on your head. And that's still my opinion. Sure, it's not polite to go hit every FQDN you see for security holes and bad mounting configuration, but _whoever_said crackers_are_polite_. It's not polite to walk down the street turning everyones' doorknob, but it might just work if everyone doesn't lock their doors. Our responsibility as network administrators is to (1) understand our system, and (2) use it to its fullest. If you don't do (1), you can't do (2), and not doing (1) often leaves a system vulnerable. If a person of deviant intent (read ``cracker'') notices a door (read ``daemon'') is standing open at your house (read ``Internet host''), and he intrudes and causes trouble, you must be willing to accept part of the blaim beforehand. Sure, you didn't make him go in, but you didn't ``use your system to its fullest''. Remember, on the Internet, we are defensive (read ``passive aggressive''). - Mark ------------------------------------------------------------------------------ Mark R. Lindsey Join the Confederation of Future Computer Professionals! mlindsey@nyx10.cs.du.edu finger me for more info From Firewalls-Owner@GreatCircle.COM Wed Jan 5 21:06:25 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25853; Wed, 5 Jan 94 21:06:25 GMT Received: from gropo.tgv.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25846; Wed, 5 Jan 94 13:06:16 PST Received: by gropo.tgv.com (5.65/DEC-Ultrix/4.3) id AA07805; Wed, 5 Jan 1994 13:07:43 -0800 Message-Id: <9401052107.AA07805@gropo.tgv.com> To: firewalls@greatcircle.com Subject: Re: Opinion requested In-Reply-To: Your message of "Wed, 05 Jan 94 09:58:12 EST." <9401051456.AA27758@ftp.com> Date: Wed, 05 Jan 94 13:07:42 -0800 From: "Michael P. Reilly" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I would consider any attempt to access my machines without being invited (i.e., given a login account, responding to my announcing anonymous ftp, etc.) to be at best rude and at worst an attempt to break in and hurt the machines. I view this as similar to just walking up to someone's home and trying the door knob just to see if it was unlocked. How could someone justify this behavior? Mike From Firewalls-Owner@GreatCircle.COM Wed Jan 5 21:10:03 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25884; Wed, 5 Jan 94 21:10:03 GMT Received: from runner.knoware.nl by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25875; Wed, 5 Jan 94 13:09:53 PST Received: by runner.knoware.nl (5.64/A/UX-3.00) id AA23680; Wed, 5 Jan 94 22:13:28 GMT Date: Wed, 5 Jan 1994 22:07:20 +0000 (WET) From: "J.P. Mante" Subject: Re: Opinion requested (fwd) To: firewalls@GreatCircle.COM Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Such behaviour smacks of rebel adolescent "nosing round" to see what >actions you can get away with, without being "found out". >"Sure I copied your password file, 'cos it was possible. > - but I wasn't going to *DO* anything with it!" Well I feel that there is a considerable difference between checking for an anon ftp, and making use of a flaw to copy somebodies passwd file. In my own case if I were to see an opportunaty to copy a passwd file I would inform the systems owner of that flaw. If somebody has an anon ftp I would consider it public. Greetings -Peter From Firewalls-Owner@GreatCircle.COM Wed Jan 5 21:15:08 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25906; Wed, 5 Jan 94 21:15:08 GMT Received: from cheetah.llnl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25897; Wed, 5 Jan 94 13:14:58 PST Received: from localhost (karyn@localhost) by cheetah.llnl.gov (8.6.4/8.6.4) id NAA29509; Wed, 5 Jan 1994 13:16:22 -0800 Date: Wed, 5 Jan 1994 13:16:22 -0800 From: Karyn Pichnarczyk Message-Id: <199401052116.NAA29509@cheetah.llnl.gov> To: wwj@candela.cfr.nist.gov, firewalls@greatcircle.com Subject: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Why does anyone expect people to behave differently on the internet than in society in general? Walter W. Jones Because when the Internet (Arpanet) began, those on it realized it was a privilege to have this sort of access, and treated everyone on the net with respect due to the pride you had in your privilege. Those people also realized that the privilege could be easily taken away, and that the net was likely to be removed if abuse was allowed to occur. Now people regard the Internet like they have a RIGHT to access it, and treat it with associated carelessness. They know if they abuse the net, they will retain access anyhow, so abuse is prevalent. And system managers realize that if they restrict access to a person, that person can easily find another inlet to the net, so many system managers just give up. To answer your question, people expect others to behave differently because they remember the idyllic beginnings of the net, and wish to retain that aura of privilege and pride and respect. karyn From Firewalls-Owner@GreatCircle.COM Wed Jan 5 13:28:02 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25385; Wed, 5 Jan 94 19:29:12 GMT Received: from hac2arpa.hac.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25378; Wed, 5 Jan 94 11:28:53 PST Received: from eden.hac.com by hac2arpa.hac.com (4.1/SMI-DDN) id AA03535; Wed, 5 Jan 94 11:30:10 PST Received: from ghost.hac.com by eden.HAC.COM (PMDF #2669 ) id <01H7BLMZPB8G8WWAAZ@eden.HAC.COM>; Wed, 5 Jan 1994 11:29:50 PST Received: by ghost.hac.com (4.1/SMI-4.1) id AA03100; Wed, 5 Jan 94 11:29:31 PST Date: 05 Jan 1994 11:29:31 -0800 (PST) From: kemasa@ghost.hac.com (Kemasa) Subject: Re: Opinion requested To: Firewalls@GreatCircle.COM, randy@megatek.com Message-Id: <9401051929.AA03100@ghost.hac.com> Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From: randy@megatek.com (Randy Davis) > >kemasa@ghost.hac.com wrote: >... > Reality check time... Quite true, but listen closely to what you are saying. > Just what do you propose to *do* if someone "checks the locks on your >windows"? If they have their own internet site and have done no damage to >your site in any provable way, then I'd say you are out of luck. Whining >that it "should not be considered acceptable behaviour nor should it be >tolerated" is basically useless and worse, unenforcable. There is not much you can do, BUT people should not say that it is acceptable. Their employers SHOULD take action against them. Other sites should take action against them if possible. For you to say that should things should be expected (true) and that there is nothing you can do about it so it should not bother you when someone does it is actually part of the problem. You accept it. You tolerate it. If I had someone working for me who was doing this I would fire them if at all possible. Each site and each person can take action and do something about it so that people do not consider this acceptable behaviour. > It *should* be assumed that someone is going to try your locks; ignoring >the fact is simply burying your head in the sand and hoping it won't happen. >With that said, I also will follow-up attempts to get into my firewall from >the outside, and have mailed a number of "desist" messages to users and >their administrators. So, if someone tries your locks you should do nothing unless they cause some damage? I never said that you should do nothing, because the sad fact is that you have to, but I did say that people should not view this as acceptable. Anarchy is not the way to live. > However, I think we all agree that "security through obscurity" is just a >stupid hope that no one will try your unlocked door... Yes. >|Care to give your home address so that people can probe your security >|there? > > The two aren't that analogous. Nice try, though. Incorrect. Kemasa. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 21:40:42 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26130; Wed, 5 Jan 94 21:40:42 GMT Received: from asilomar.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26123; Wed, 5 Jan 94 13:40:31 PST Received: from localhost by asilomar.netcom.com (8.6.4/SMI-4.1) id NAA06654; Wed, 5 Jan 1994 13:45:25 -0800 From: owen@netcom.com (Owen DeLong) Message-Id: <199401052145.NAA06654@asilomar.netcom.com> Subject: Re: opinions on firewall probing To: firewalls@greatcircle.com Date: Wed, 5 Jan 1994 13:45:25 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2408 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There are two questions here. The first one is the ethical or moral question of what is or is not socially acceptable behavior. This question is, I believe, "Is it, or is it not, OK to attempt to access xyz service on a abc host without an invitation." I think the answer to that is complex and depends on many factors. For example, if the attempt is made to access anonymous ftp or deliver mail through SMTP, I think the answer is that this is OK. On the other hand, I think that an attempt to access FTP as someone other than anonymous or an attempt to invoke debug or wizard mode in SMTP is NOT OK. However, what is socially acceptable behavior vs. what is not can be combined with $.50 to purchase a cup of coffee. The second one is the legal, and pragmatic question. This question is, I believe, "What can I do to prevent unauthorized access to my system with minimal inconvenience to legitimate users. Can I prosecute someone for unauthorized access when I left the door wide open?" The answer to the first part of this question is complex, and pretty much defines what this mailing-list is all about. The second part, on the other hand, lies in the purview of the courts and the lawyers. My initial take on the way the laws are structured is that you should be able to prosecute this person if you can show a harmful intent. Now we made the first question part of the second question, and the complexity grows from there. Many new social and legal issues face us as we stand at the edge of the hyper-information age. This is one of the primary issues that must be decided. We must set some level of social policy and legal policy about these things. Unfortunately, we are doing this with a society and a legal system which both lack the experience to truly understand the impact of the solutions that may be suggested. The members of this list are probably some of the most qualified people available today, and we don't agree. My opinion... I lock the doors and windows on my house. I don't want anyone in there uninvited. I don't want anyone in my computer uninvited either. I lock them up to the extent I consider feasible, and try to remain aware of the amount risk I am taking. One thing for sure. There is no simple answer. Owen DeLong owen@DeLong.ORG (At home on the Internet) owen@DeLong.SJ.CA.US (At home on the Internet) KB6MER@KB6MER.#NOCAL.CA.USA.NA (HAM Radio BBS) From Firewalls-Owner@GreatCircle.COM Wed Jan 5 21:48:04 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26166; Wed, 5 Jan 94 21:48:04 GMT Received: from ENH.NIST.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26159; Wed, 5 Jan 94 13:47:47 PST Received: from candela.cfr.nist.gov by ENH.NIST.GOV (PMDF V4.2-13 #4653) id <01H7BWQ8E87K005FMG@ENH.NIST.GOV>; Wed, 5 Jan 1994 16:47:02 EDT Received: by candela.cfr.nist.gov (920330.SGI/911001.SGI) for @enh.nist.gov:era@ncar.ucar.edu id AA09993; Wed, 5 Jan 94 16:41:55 -0500 Date: Wed, 05 Jan 1994 16:41:55 -0500 From: wwj@candela.cfr.nist.gov (Walter W. Jones) Subject: Re: Opinion requested To: era@ncar.ucar.edu (Ed Arnold) Cc: firewalls@GreatCircle.COM, hobbit@ftp.com, lec.Muffett@UK.Sun.COM Message-Id: <9401052141.AA09993@candela.cfr.nist.gov> Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>From: era@ncar.ucar.edu (Ed Arnold) >>Reply-To: era@ncar.ucar.edu (Ed Arnold) >> >>Walter Jones wrote: >> >>> Why does anyone expect people to behave differently on the internet than in >>> society in general? >> >>I was under the impression that studies have rather conclusively shown >>that people will say and do things in the electronic media, which they >>would never think of doing in real life, i.e. when they are interacting >>with real people in real time. >> Actually, that is a very interesting observation. I was coming at it from the opposite point of view, namely that there seems to be an expectation that everyone on the internet will be well behaved. I was only trying to point out that that is probably not a realistic expectation. Walter W. Jones, Fire Modeling Group, wwj@nist.gov Building and Fire Research, National Institute of Standards and Technology From Firewalls-Owner@GreatCircle.COM Wed Jan 5 22:12:12 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26307; Wed, 5 Jan 94 22:12:12 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26299; Wed, 5 Jan 94 14:12:02 PST Received: by terminus.cs.umb.edu id AA25782 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 5 Jan 1994 17:13:29 -0500 Date: Wed, 5 Jan 1994 17:13:29 -0500 From: "John B. Brown" Message-Id: <199401052213.AA25782@terminus.cs.umb.edu> To: mjr@tis.com, reh@cs.UMD.EDU Subject: Re: Opinion requested Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Date: Wed, 5 Jan 94 14:26:33 -0500 > From: reh@cs.UMD.EDU (Richard Huddleston) > To: mjr@tis.com < deletions > > I'd wager that if someone walked into your yard and stood next to > a window ( instead of the front door ) you'd consider it a security > event. > Street->yard->house(->living-room?->bedroom?) is perhaps an > inappropriate way to think of all this. I'm not saying I know what > *is* an appropriate way; perhaps street->building->condo -- where the > "building" is the common environment provided by the connection service > provider to all clients. Not two years ago there was a great test on the net of NFS mounting from Washington state to where ever. The object was connectivity. Now, is it becoming the equivalent of rape, as implied above? Get real. If you advertise the mount, someone will use it. If you don't want someone mounting your partitions, set your permissions correctly. Please, don't liken some stray EMF to war or intrusion of your bedroom. Shalom, JBB. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 14:16:19 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25206; Wed, 5 Jan 94 19:04:26 GMT Received: from hac2arpa.hac.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25199; Wed, 5 Jan 94 11:04:11 PST Received: from eden.hac.com by hac2arpa.hac.com (4.1/SMI-DDN) id AA03168; Wed, 5 Jan 94 11:05:28 PST Received: from ghost.hac.com by eden.HAC.COM (PMDF #2669 ) id <01H7BKRURNR48WWF44@eden.HAC.COM>; Wed, 5 Jan 1994 11:04:46 PST Received: by ghost.hac.com (4.1/SMI-4.1) id AA03049; Wed, 5 Jan 94 11:04:45 PST Date: 05 Jan 1994 11:04:45 -0800 (PST) From: kemasa@ghost.hac.com (Kemasa) Subject: Re: Opinion requested To: firewalls@GreatCircle.COM, hobbit@ftp.com, kemasa@ghost.hac.com, mjr@tis.com Message-Id: <9401051904.AA03049@ghost.hac.com> Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From: mjr@tis.com >... > This is because having my house attached to the ground, and >therefore reachable, is not exactly optional. Windows ARE optional, so is having a house as you can have an apartment with NO ground floor windows. You could also say the same thing for cars or anything else. > The analogy of house::computer network is a terrible one, >and I wish people would stop using it. By default networks are >not interconnected. By default houses are connected to streets. >If the default was that houses each existed in separate, secure >universes, and we had complete control over the size and form >of our connection between our homes and the rest of the universe, >then the analogy might be a little more sensible. To do business you might need such a connection. Do you want to contend that having a phone in your house should permit people to call that number at all hours of the day and night looking for modems or just checking to see what is available? You can add gates to your house, bars to your window, etc., but should you have to in order to prevent people from attempting to get in to look around? You are just trying to justify anti-social behaviour which should not be acceptable and that it the bottom line. I personally do not care if the computer is connected to every network in the world, has modems and has no passwords on the accounts, it STILL does not make it right for someone to use the system when they are not authorized. It might be stupid to have such a system, but that is a different point. You argue that people should be *FORCED* to spend a lot of time and effort on security because otherwise they are allowing such access. This is WRONG and a very bad attitude to have. I guess it is an indication of what this society has come to. If you don't lock it up then it is the victim's fault as the poor criminal could not help themselves. Sad, very sad. > If being connected to the street were optional, how many >members of this list would have anything more connected than a >single, solid steel front door with an alarm on it? (Maybe a few >windows 3 storeys up, with steel grating) Why should you have to do that? Think about it. >... > Checking for NFS service access does not necessarily imply >an attempted breakin. No and checking to see if a door is unlocked does not mean that the person will enter, but then the question comes is why is someone checking when they should not enter/use such things when they are not authorized? There is NO reason to do such checking on someone's machine without permission, therefore it should not be done. Unethical people might do it though. >... > Definitely. Another thing you need to do is decide what >constitutes a threat. If you can state, as part of your security >analysis, that you've secured a service (let's say, NFS) then it's >reasonable to state that someone probing that service is not a >threat, or even an attempted break-in. It may indicate they're a >bad neighbor, but, just like when you have bad neighbors in the >real world, there's not a lot you can *DO* about them unless they >are breaking the law by coming onto your property (see below). Yes, but the point is in this case is that the person should not be attempting to get in, NOT what security the other person should have. > An example: I run a system that's a major potential >target. It's a password-less system, using SecurID for authentication. >Therefore, it's not a problem if someone steals the password file >from the system. If I got upset every time someone tried to FTP >out the password file from its anonymous FTP area, I'd spend 40 >hours a week writing irate mail to other systems administrators. Yes, but you should not have to do all that. It is a fact that you do, but people should not be encouraged to do such things nor should it be tolerated. You of all people should not think such things are acceptable. >... >>Care to give your home address so that people can probe your security >>there? > > 3018 Guilford Ave, > Baltimore, MD > 21218 > > BTW, I just bought a new .44mag Desert Eagle, and a wireless >burglar alarm system, so if you're inclined to test my security, make >sure you have a pretty good bullet proof vest, and pray I don't try for >a head shot. You are not always home. Think about that. Now everyone on the list and anyone this gets forwarded to knows where you live. Think about the security aspects of that. Kemasa. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 14:20:00 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25554; Wed, 5 Jan 94 19:56:53 GMT Received: from d.ecc.engr.uky.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25547; Wed, 5 Jan 94 11:56:35 PST Received: from s.ecc.engr.uky.edu by d.ecc.engr.uky.edu (5.59/25-eef) id AA25121; Wed, 5 Jan 94 14:59:49 EST Received: by s.ecc.engr.uky.edu (4.1/SMI-4.1) id AA00651; Wed, 5 Jan 94 14:59:11 EST Date: Wed, 5 Jan 94 14:59:11 EST From: morgan@engr.uky.edu (Wes Morgan) Message-Id: <9401051959.AA00651@s.ecc.engr.uky.edu> To: firewalls@GreatCircle.COM Subject: Re: Dummy Ident server Cc: u84718@sccux1.msd.ray.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From: "Bill Gianopoulos" > >A couple of months ago, there was some discussion on this list about what a >firewall machine should do in response to an "ident" query. [...] > >[ IP spoofing scenario, generating ident queries back to *real* firewall ] > >I would like to return the correct "NO-USER" error condition (indicating >this connection did NOT come from me) rather than the incorrect "HIDDEN-USER" >error condition (indicating this connection did come from me, but I am not >going to tell you the user name). This sounds both reasonable and proper. >So, my question is, does anyone know of a public domain ident server which >would work under Ultrix 4.3 for which I could obtain source? I've appended the blurb (reformatted to save space) for the most recent version of Peter Erikkson's pidentd implementation, which works under Ultrix (and most other Unix variants). Interested parties may join Peter's ident-announce mailing list by sending an email request to "ident-announce-request@lysator.liu.se". --Wes >>From: Peter Eriksson >>To: ident-announce@lysator.liu.se >>Subject: Pidentd 2.2 - now available >> >>This message announces the availability of Pidentd version 2.2, a server >>that implements the IDENT (RFC1413) protocol for Unix operating systems. >> >>It is available for anonymous FTP from ftp.lysator.liu.se in the >>directory pub/ident/servers as pidentd-2.2.tar.gz. You can also find >>it on the sites that mirror this directory, for example ftp.uu.net in >>the directory pub/networking/ident/servers. >> >>You can also get it via email by sending an email to the address >>'ftpserv@lysator.liu.se' with a letter body looking like: >> >> UUSEND pub/ident/servers/pidentd-2.2.tar.gz >> QUIT >> >>Pidentd 2.2 supports the following operating systems: >> >> SunOS 3, 4 and 5, BSD/386 from BSD Inc, 386BSD or NetBSD, 4.3BSD Reno or >> Tahoe, Sequent Dynix 2 or 3, MIPS RISC/OS 4, SGI IRIX 4, HP-UX 7, 8 and 9, >> SCO Unix SysV R3.2 (v4.0 and v4.1) SVR4, AT&T's SVR4, Apple A/UX 2 and 3, >> DEC Ultrix 3 and 4, DEC Alpha AXP OSF/1, Linux 0.99.13q or later, Cray >> UNICOS 6, Convex ConvexOS, NeXTStep 2, 3.0 or 3.1, Pyramid dualPort OSx 4 >> >>/Peter >> >>Peter Eriksson pen@lysator.liu.se >>Lysator Academic Computer Society ...!uunet!lysator.liu.se!pen >>University of Linkvping, Sweden I'm bored again - flame me! -- Wes Morgan Systems Administrator morgan@engr.uky.edu UK College of Engineering From Firewalls-Owner@GreatCircle.COM Wed Jan 5 22:35:20 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26411; Wed, 5 Jan 94 22:35:20 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26404; Wed, 5 Jan 94 14:35:13 PST Received: by terminus.cs.umb.edu id AA25868 (5.65c/IDA-1.4.4 for Firewalls@greatcircle.com); Wed, 5 Jan 1994 17:36:38 -0500 Date: Wed, 5 Jan 1994 17:36:38 -0500 From: "John B. Brown" Message-Id: <199401052236.AA25868@terminus.cs.umb.edu> To: Firewalls@greatcircle.com, SEB@LNS62.LNS.CORNELL.EDU, randy@megatek.com Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Date: Wed, 05 Jan 1994 14:15:43 -0500 (EST) > From: "Selden E. Ball, Jr." < deletions > > Unfortunately, probing for anonymous ftp accounts is also done by > those who are seeking sites for distributing illegally cracked software > and other antisocial publications. I finally figured out what the problem is; some sites are being administered by sociologists, and incompetent ones at that. A net host is not a house, a daemon is not a door, login is not a lock, and people using computers to gather what information they can are not criminals. Of course, we can always be paranoid and anti-social, and criminalize the use of the net by any but the unimaginative. After all, us americans did create the crime of trespass. Shalom, JBB. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 23:07:24 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26628; Wed, 5 Jan 94 23:07:24 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26621; Wed, 5 Jan 94 15:07:08 PST Received: by terminus.cs.umb.edu id AA26031 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 5 Jan 1994 18:08:26 -0500 Date: Wed, 5 Jan 1994 18:08:26 -0500 From: "John B. Brown" Message-Id: <199401052308.AA26031@terminus.cs.umb.edu> To: firewalls@greatcircle.com, karyn@cheetah.llnl.gov, wwj@candela.cfr.nist.gov Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Date: Wed, 5 Jan 1994 13:16:22 -0800 > From: Karyn Pichnarczyk > Why does anyone expect people to behave differently on the internet than in > society in general? > Walter W. Jones > Because when the Internet (Arpanet) began, those on it realized it was > a privilege to have this sort of access, and treated everyone on the > net with respect due to the pride you had in your privilege. Those > people also realized that the privilege could be easily taken away, > and that the net was likely to be removed if abuse was allowed to > occur. > Now people regard the Internet like they have a RIGHT to access it, > and treat it with associated carelessness. They know if they abuse > the net, they will retain access anyhow, so abuse is prevalent. And > system managers realize that if they restrict access to a person, that > person can easily find another inlet to the net, so many system > managers just give up. > To answer your question, people expect others to behave differently > because they remember the idyllic beginnings of the net, and wish to > retain that aura of privilege and pride and respect. > karyn Ah, for the good old days. Now, Delphi sells basic internet access for about $250 per year, and the buyers consider they have bought the right to use the net. That includes anyone. They would consider the net as just another "super highway" that their taxes have paid for. And, of course, they are correct. How the computer professionals respond is appalling, with all the puling and whining this thread has witnessed. Mister Jones is right on. The net is now being considered public property by the public. Shalom, JBB. PS. Your business is now on a public highway. Act accordingly. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 15:08:47 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25830; Wed, 5 Jan 94 21:04:16 GMT Received: from ncar.UCAR.EDU ([192.52.106.6]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25823; Wed, 5 Jan 94 13:04:07 PST Received: from niwot.scd.ucar.EDU by ncar.ucar.EDU (8.6.4/ NCAR Central Post Office 03/11/93) id OAA00897; Wed, 5 Jan 1994 14:05:32 -0700 Message-Id: <199401052105.OAA09780@niwot.scd.ucar.EDU> Received: from localhost by niwot.scd.ucar.EDU (8.6.4/ NCAR Mail Server 04/10/90) id OAA09780; Wed, 5 Jan 1994 14:05:31 -0700 Subject: Re: Opinion requested To: wwj@candela.cfr.nist.gov (Walter W. Jones) Date: Wed, 5 Jan 94 14:05:30 MST Cc: Alec.Muffett@UK.Sun.COM, hobbit@ftp.com, firewalls@GreatCircle.COM In-Reply-To: <9401051842.AA09329@candela.cfr.nist.gov>; from "Walter W. Jones" at Jan 5, 94 1:42 pm From: era@ncar.ucar.edu (Ed Arnold) Reply-To: era@ncar.ucar.edu (Ed Arnold) X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Walter Jones wrote: > Why does anyone expect people to behave differently on the internet than in > society in general? I was under the impression that studies have rather conclusively shown that people will say and do things in the electronic media, which they would never think of doing in real life, i.e. when they are interacting with real people in real time. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 15:10:57 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26034; Wed, 5 Jan 94 21:28:32 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26027; Wed, 5 Jan 94 13:28:22 PST Received: by terminus.cs.umb.edu id AA25376 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 5 Jan 1994 16:29:44 -0500 Date: Wed, 5 Jan 1994 16:29:44 -0500 From: "John B. Brown" Message-Id: <199401052129.AA25376@terminus.cs.umb.edu> To: firewalls@greatcircle.com, hobbit@ftp.com, kemasa@ghost.hac.com, mjr@tis.com Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: kemasa@ghost.hac.com (Kemasa) > Date: 05 Jan 1994 08:10:21 -0800 (PST) > Care to give your home address so that people can probe your security > there? I don't live in my computer. Neither does anyone else. Emitting electrons onto a wire at my computer site is NOT the same as transporting myself to your house. Use something other than emotion to think with. Shalom, JBB. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 23:20:22 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26690; Wed, 5 Jan 94 23:20:22 GMT Received: from mail.uunet.ca (uunet.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26676; Wed, 5 Jan 94 15:20:14 PST Received: from jtsv16 by mail.uunet.ca with UUCP id <58520(1)>; Wed, 5 Jan 1994 18:20:46 -0500 Received: by jts.com (/\==/\ Smail3.1.25.1 #25.17) id ; Wed, 5 Jan 94 17:53 EST Received: by lemon.jts.com (4.1/SMI-4.1) id AA10955; Wed, 5 Jan 94 17:53:41 EST From: jimc@jts.com Message-Id: <9401052253.AA10955@lemon.jts.com> Subject: Re: Opinion requested (fwd) To: firewalls@GreatCircle.COM (Firewalls at Great Circle) Date: Wed, 5 Jan 1994 17:53:41 -0500 Reply-To: jimc@jts.com Organization: JTS Computer Systems Ltd., Toronto, Canada X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 554 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Quoting smb@research.att.com: + + In short -- I'll follow up on attempts to invoke our (non-existent) + NFS daemon. (Btw, those are rather rare, though we've had a few -- + which may say something about the expectations of most users.) But + I won't ring loud alarms without further evidence. May I ask how one logs such attempts? Is there a package similar to tcp-wrappers? + + --Steve Bellovin + -- Jim Carroll | JTS Computer Systems Ltd. | The ongoing struggle of jimc@jts.com | Toronto, Ontario | Prometheus vs. Epimetheus.... From Firewalls-Owner@GreatCircle.COM Wed Jan 5 16:50:35 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26434; Wed, 5 Jan 94 22:37:00 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26426; Wed, 5 Jan 94 14:36:49 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA16719; Wed, 5 Jan 94 17:38:15 -0500 Received: from rayssd.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 173623.21625; Wed, 5 Jan 1994 17:36:23 EST Received: from sccux1.msd.ray.com by rayssd.ssd.ray.com with SMTP id AA05593 (5.65c/IDA-1.5 for ); Wed, 5 Jan 1994 17:14:46 -0500 Received: by sccux1.msd.ray.com (5.57/Ultrix3.0-C) id AA12263; Wed, 5 Jan 94 17:18:08 -0500 Date: Wed, 5 Jan 94 17:18:08 -0500 From: "Bill Gianopoulos" Message-Id: <9401052218.AA12263@sccux1.msd.ray.com> To: firewalls@greatcircle.com, morgan@engr.uky.edu Subject: Re: Dummy Ident server Cc: u84718@sccux1.msd.ray.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>It is available for anonymous FTP from ftp.lysator.liu.se in the >>directory pub/ident/servers as pidentd-2.2.tar.gz. You can also find Excuse the dumb question, but exactly what does one do with a ".gz" file? -- Bill Gianopoulos Raytheon Company From Firewalls-Owner@GreatCircle.COM Wed Jan 5 16:58:05 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26459; Wed, 5 Jan 94 22:39:08 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26451; Wed, 5 Jan 94 14:38:59 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17566; Wed, 5 Jan 94 17:40:14 -0500 Received: from rayssd.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 173807.21711; Wed, 5 Jan 1994 17:38:07 EST Received: from sccux1.msd.ray.com by rayssd.ssd.ray.com with SMTP id AA06047 (5.65c/IDA-1.5 for ); Wed, 5 Jan 1994 17:25:49 -0500 Received: by sccux1.msd.ray.com (5.57/Ultrix3.0-C) id AA12580; Wed, 5 Jan 94 17:29:12 -0500 Date: Wed, 5 Jan 94 17:29:12 -0500 From: "Bill Gianopoulos" Message-Id: <9401052229.AA12580@sccux1.msd.ray.com> To: firewalls@greatcircle.com, morgan@engr.uky.edu, u84718@sccux1.msd.ray.com Subject: Re: Dummy Ident server Cc: u84718@sccux1.msd.ray.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>It is available for anonymous FTP from ftp.lysator.liu.se in the >>>directory pub/ident/servers as pidentd-2.2.tar.gz. You can also find >Excuse the dumb question, but exactly what does one do with a ".gz" file? Never mind, I found gzip. -Bill From Firewalls-Owner@GreatCircle.COM Wed Jan 5 17:13:10 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26444; Wed, 5 Jan 94 22:37:32 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26435; Wed, 5 Jan 94 14:37:20 PST Received: by relay.tis.com; id AA00784; Wed, 5 Jan 94 17:38:34 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma000777; Wed Jan 5 17:37:41 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA06172; Wed, 5 Jan 94 17:37:36 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA06904; Wed, 5 Jan 94 17:37:34 EST Date: Wed, 5 Jan 94 17:37:34 EST From: mjr@tis.com Message-Id: <9401052237.AA06904@otter.tis.com> To: firewalls@GreatCircle.COM Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> An example: I run a system that's a major potential >>target. It's a password-less system, using SecurID for authentication. >>Therefore, it's not a problem if someone steals the password file >>from the system. If I got upset every time someone tried to FTP >>out the password file from its anonymous FTP area, I'd spend 40 >>hours a week writing irate mail to other systems administrators. > >Yes, but you should not have to do all that. It is a fact that you >do, but people should not be encouraged to do such things nor >should it be tolerated. You of all people should not think such >things are acceptable. It's a question of risk assessment. Just as with anything in security, you have to weigh the cost against the benefits, and decide what's best for you. I agree completely that nobody *should* have to worry about security at all. Nor, for that matter, should anyone have to worry about being robbed or killed or having one's savings and loan looted... But that's not reality. Reality is that if you have some amount of effort you can afford to expend on security, it's probably more generally useful to expend the effort to make your firewall so that you don't *HAVE* to care if someone steals your password file. That means that complaining about and tracking down people who do is now optional -- something you can choose to spend your time on, if you have any left and want to help society as a whole. I used to track down attacks against one of my firewalls and decided it just wasn't worth it, after a while. After all, most of the folk who were doing it are supposed to be getting their educations about morality from their parents and teachers, not from *me*!! :) Perhaps if I'd had a way to give them a spanking remotely, then it would have been worth while, but it was more cost effective for me to just make sure my security was so tight I didn't have to worry about them. This brings up the whole issue of active versus passive defense. When we designed the firewall toolkit, we put a fair bit of effort into figuring out how to lateral-think problems so that security was inherently strengthened by design, rather than requiring security to be strengthened by actively probing for bugs and patching holes. One example of this is the idea of chrooting to ~ftp before you invoke ftpd. Solves the whole problem of ftpd security holes, or takes a big step in that direction, and it saves having to actively monitor the 'net for ftpd-related security holes and patches. The ideal situation is when you by default have security without having to take action, which means you still *CAN* take action if you want to do some college kids' parents' job and teach him about life when he tries to crack your firewall. Another example of figuring out where to put one's effort with respect to security was my publishing my home address, just now. The fact is that if anyone *wanted* my home address, they could get it. Trying to obscure it is less cost effective then defending my home. (I buy lots of stuff from catalogs, I'm sure I'm in all those CDROMS of catalog mailing lists you can buy for $29) mjr. From Firewalls-Owner@GreatCircle.COM Thu Jan 6 01:20:25 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27266; Thu, 6 Jan 94 01:20:25 GMT Received: from interlock.wdni.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27253; Wed, 5 Jan 94 17:20:10 PST Received: by interlock.wdni.com id AA03551 (InterLock SMTP Gateway 1.1 for firewalls@greatcircle.com); Wed, 5 Jan 1994 17:21:28 -0800 Received: by interlock.wdni.com (Internal Mail Agent-1); Wed, 5 Jan 1994 17:21:28 -0800 Date: Wed, 5 Jan 1994 17:12:04 -0800 (PST) From: Jeff Welty Subject: Summary for Re: Opinions Requested To: firewalls@greatcircle.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Could we summarize this whole discussion by saying that: 1) Security is the administrator's responsibility. 2) There are always unethical people who will try to get *in*. 3) An attempt at an anonymous ftp is not a critical security problem because ftp archive sites are THE defacto method of making material available to the public 4) An attempt to do an NFS mount from an unauthorized entity deserves significant attention on the part of an administrator. 5) Unethical behavior needs more clarification/definition and then needs to be discouraged *---------------------------------------------------* | Jeff Welty -=- (206)924-6390 | | WTC-1A3 | | Weyerhaeuser Company | | Tacoma, WA 98422 | *---------------------------------------------------* From Firewalls-Owner@GreatCircle.COM Wed Jan 5 17:24:15 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26350; Wed, 5 Jan 94 22:21:05 GMT Received: from large.cisco.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26343; Wed, 5 Jan 94 14:20:45 PST Received: from localhost by large.cisco.com with SMTP id AA12946 (5.67a/IDA-1.5 for ); Wed, 5 Jan 1994 14:21:45 -0800 Message-Id: <199401052221.AA12946@large.cisco.com> To: kemasa@ghost.hac.com (Kemasa) Cc: firewalls@greatcircle.com Subject: Re: Opinion requested In-Reply-To: Your message of "05 Jan 1994 11:41:51 PST." <9401051941.AA03123@ghost.hac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 05 Jan 1994 14:21:44 -0800 From: David Carrel Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Kemasa, > >Maybe a better analogy is to a downtown shopping district. I don't wait > >for an invitation to enter a store, I try the door and walk in. If the > >door is locked, then I won't break it down, but if it's unlocked, I go > >right in. > > The problem with this is that it is assumed that is business in a shopping > district is open to the public. Most companies on the internet are not > there for people to access their machines. Maybe if you want to attempt > such an argument that you should look at from the standpoint of checking > the offices in that business, try walking behind the counter, try the > cash register, try wandering into the "private" areas of the business > (which generally say employees only). If you are talking about a service > provider then you would be correct to some extend, but there are limits > as to what people *know* is acceptable. Sure, if you put up a sign that says "employees only" then I do not have a right to walk in. If you don't make your NFS mount points publicly mountable, then I will read that as "keep out" or "private". But if you make them public, then I will treat them as such. If a company connects itself to the internet, then they have created an avenue to the public world. If they do not create a door for themselves, then they are open to the public and I will treat it as such. All I am saying is that when you connnect to the public networks (which I pay for the right to access) you must tell me if you don't want me to come in to your piece of the net. A firewall is such a signpost. I will respect it. Others will not, but that is annother issue altogether. > >I guess the biggest point that I am trying to make here is that we can't > >keep trying to describe our networks in terms of suburban tree lined > >neighborhoods. They're just different beasts. Networks are used for the > >exchange of information. Most of the information that I get off the net, I > >have to go out and find. No one sends me a personal invitation. The only > >way that information access can scale on the "Information Highway" is to > >assume permission until you are denied. This is also the only RESPONSIBLE > >way for a security administrator to look at their own site. > > People DO send you personal invitations. There are lists of anonymous > FTP sites as well as other means of getting information. Archie is > such a means of inviting you to get the information. NO NO NO!! archie is not the definitive invitation list, Archie is just a tool that pokes around, just as I do, and sees what is available. > How many people give out NFS access publically? Do you call phone numbers > in the hope of finding modem and then assume that you have permission > until you are denied? NO! This is wrong and you know it. I know no such thing!! If they ask for a login name and password and they don't accept guest logins, then I know that I am not wanted. Until then, I am free to ask if I may enter their system. > I agree that you have to have a security person take care of the machine, > but the point that I am trying to make is that regardless of what security > is done on the machine, the person who attempts to access the machine > without authorization is WRONG. You are forgetting about causality. I don't know if I have authorization or not until I ask. I ask by trying to login as guest or use anonymous ftp or mount a filesystem. If you set up you system to not grant me access, then I know that I am not wanted. Again, I hate silly house analogies, but there is no law against nocking on your door and asking if I may come in. If you don't answer, that can be assumed to be a "don't come in" response. But if I walk up to your shop and the automatic door opener opens the door, I WILL walk in. > Sigh ... If you can do it then you consider it acceptable. Sounds like a > child who does not want to get permission, "but you never said I couldn't". > There are methods which such things are made public and to try to find > a hole where someone made a mistake is wrong. You can always ask or > is that too much to ask? I think I should be sighing here. Your pejorative little snipe is annoying. You need to be clear on what your responsibilities are. I am not a mind reader, and I do not know what your intentions for access are at your site. If I look and things are open, I will look further. I'm not talking about breaking in. I do not assume that guessing a password or using a system bug to get on your system is an invitation, but a guest account or anonymous FTP is! ---------------------------------------------------------------------------- David Carrel | E-mail: carrel@cisco.com Security Development, Cisco Systems | phone: (415) 324-5207 P.O. Box 3075, 1525 O'Brien Dr. | fax: (415) 903-7111 Menlo Park, Ca, 94025-1435 | These words are mine, not Cisco's ---------------------------------------------------------------------------- From Firewalls-Owner@GreatCircle.COM Wed Jan 5 17:48:07 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26847; Thu, 6 Jan 94 00:06:20 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26840; Wed, 5 Jan 94 16:06:08 PST Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA18288; Wed, 5 Jan 94 19:07:35 -0500 Date: Wed, 5 Jan 94 19:07:35 -0500 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9401060007.AA18288@bedrock.cs.UMD.EDU> To: jbb@cs.umb.edu Subject: Re: Opinion requested Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I wrote: > Street->yard->house(->living-room?->bedroom?) is perhaps an > inappropriate way to think of all this. I'm not saying I know what > *is* an appropriate way; perhaps street->building->condo -- where the > "building" is the common environment provided by the connection service > provider to all clients. JBB replied: Not two years ago there was a great test on the net of NFS mounting from Washington state to where ever. The object was connectivity. Now, is it becoming the equivalent of rape, as implied above? To which I can only say: Wait a minute: who's implying anything about rape? It's a progression of increasing PRIVACY.^C Street(public)->yard(yours, but easily accessed by anyone)->house(doors, windows, locks and walls)->living-room(where you typically entertain guests)->bedroom(only very special/trusted folks). Further, I'm saying that perhaps this is too vague of a way to think about it. I try to resist stretching a metaphor where it doesn't fit. Since we still, apparently, have to think of things like net access in terms of what precedents have been established about "boundaries" and tort statues, it seems to me that a better metaphor is one where we don't have a vast gray area. Richard From Firewalls-Owner@GreatCircle.COM Wed Jan 5 17:50:48 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26926; Thu, 6 Jan 94 00:23:53 GMT Received: from world.std.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26912; Wed, 5 Jan 94 16:23:42 PST Received: by world.std.com (5.65c/Spike-2.0) id AA21324; Wed, 5 Jan 1994 19:25:09 -0500 From: heiser@world.std.com (Bill Heiser) Message-Id: <199401060025.AA21324@world.std.com> Subject: Re: Opinion requested To: firewalls@greatcircle.com Date: Wed, 5 Jan 1994 19:25:08 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 458 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk wwj@candela.cfr.nist.gov (Walter W. Jones) wrote: > Why does anyone expect people to behave differently on the internet than in > society in general? The one way in which Internet is different than "society in general" is the perceived anonymity on the Internet. Sitting in a dark dank dorm room typing on a PC is a lot different than walking down a public street shining a flashlight in someone's windows. -- Bill Heiser heiser@world.std.com From Firewalls-Owner@GreatCircle.COM Thu Jan 6 01:59:43 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27581; Thu, 6 Jan 94 01:59:43 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27574; Wed, 5 Jan 94 17:59:33 PST Received: by terminus.cs.umb.edu id AA26733 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 5 Jan 1994 21:00:52 -0500 Date: Wed, 5 Jan 1994 21:00:52 -0500 From: "John B. Brown" Message-Id: <199401060200.AA26733@terminus.cs.umb.edu> To: jbb@cs.umb.edu, reh@cs.UMD.EDU Subject: Re: Opinion requested Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Richard, Your request for a better metaphor is premature. A description of the real thing is adequate. > From reh@cs.UMD.EDU Wed Jan 5 14:07:35 1994 < much deleted > > Since we still, apparently, have to think of things like net access in > terms of what precedents have been established about "boundaries" and > tort statues, it seems to me that a better metaphor is one where we don't > have a vast gray area. We have an electronic communications system, researched and funded from taxes, and now open to the public. Not a house. No living-rooms, dens, bedrooms, or even wall safes. An electronic communications system. No one has to move from their chair to access any host on the net. The medium of data protection is the software operating on the host. No walls, No cops with guns and dogs, just zeros and ones in the cpu. It may seem satisfying to anthropomorphise the net, but the direction that takes us is away from the purpose of free and easy access to information. Even the politicians are calling for an 'Information Super Highway' to set the tone for open access. The other mistake is that the furhter we get from the truth, with metaphors and analogies, the more rigid the response from 'outraged and offended' users and administrators becomes. I don't think anybody makes money by locking up the information that helps inform decisions. Many for-profit companies have anonymous ftp, dial-in bulletin boards, etc., and they manage to handle their proprietary information with secure access. Networked file access is here to stay, and even grow. Don't bemoan the attempt to inform. Set your machines to do what you want. The software is all out there on the net, much of it free, and all it takes is spending the time to learn how to use it to do what you want. Please, no more houses and bedrooms, huh? Shalom, JBB. From Firewalls-Owner@GreatCircle.COM Wed Jan 5 18:01:40 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26924; Thu, 6 Jan 94 00:23:51 GMT Received: from world.std.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26911; Wed, 5 Jan 94 16:23:41 PST Received: by world.std.com (5.65c/Spike-2.0) id AA18376; Wed, 5 Jan 1994 19:14:27 -0500 From: heiser@world.std.com (Bill Heiser) Message-Id: <199401060014.AA18376@world.std.com> Subject: Re: Opinion requested To: firewalls@greatcircle.com Date: Wed, 5 Jan 1994 19:14:26 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 588 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Selden E. Ball, Jr." wrote: > A prudent network administrator of a probed site should notify the > administrator responsible for the system where the probe initiated. > It is then up to the remote administrator to take approprate action. Wouldn't this "notification" quickly turn into a full-time job? How many "probes" does the typical Internet site receive on a daily basis anyway? Besides, wouldn't "most" cracker-wannabees spoof their source addresses anyway? How would you track them down in this case? -- Bill Heiser heiser@world.std.com From Firewalls-Owner@GreatCircle.COM Wed Jan 5 18:10:58 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27021; Thu, 6 Jan 94 00:46:49 GMT Received: from almaden.ibm.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27014; Wed, 5 Jan 94 16:46:39 PST Message-Id: <9401060046.AA27014@mycroft.GreatCircle.COM> Received: from ALMVMA by almaden.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5154; Wed, 05 Jan 94 16:47:52 PST Date: Wed, 5 Jan 94 16:47:51 PST From: enge@almaden.ibm.com Apparently-To: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk To: firewalls@greatcircle.com Subject: Re: Opinion requested Reply-To: enge@almaden.ibm.com News-Software: UReply 3.1 References: <199401051848.AA26597@large.cisco.com> One thing to remember is that the "model" of the Internet is changing rapidly. While in the "old" days, it was mostly universities and government, it is rapidly becoming a commercial network. Lots of companies (mine included) are using Internet for commercial purposes (like exchanging work with an outside developer or contractor). Many of the nodes being added are for these uses. A commercial user probably will not want a bunch of people banging at their nodes looking to see "what's available." I think most of the analogy I mentioned earlier holds true. There will be "private homes" and "stores" along the information highway. The "stores" will advertise in a number of ways and have public access. The "homes" will expect their privacy to be respected. How to we construct the equivalent of "No trespassing" and "No salesmen" signs electronically? Roy Engehausen -- enge@almaden.ibm.com From Firewalls-Owner@GreatCircle.COM Wed Jan 5 18:18:09 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27623; Thu, 6 Jan 94 02:02:06 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27613; Wed, 5 Jan 94 18:01:52 PST Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27957; Wed, 5 Jan 94 21:03:10 -0500 Received: from megatek.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 210122.28354; Wed, 5 Jan 1994 21:01:22 EST Received: from ninja.megatek by megatek.com (4.1/smail2.5/09-29-87) id AA12821; Wed, 5 Jan 94 17:59:50 PST Received: by ninja.megatek (4.1/SMI-4.1) id AA28201; Wed, 5 Jan 94 17:59:48 PST Date: Wed, 5 Jan 94 17:59:48 PST From: randy@megatek.com (Randy Davis) Message-Id: <9401060159.AA28201@ninja.megatek> To: Firewalls@GreatCircle.COM Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk [kemasa@ghost.hac.com (Kemasa) writes:] |Quite true, but listen closely to what you are saying. You need to read BOTH paragraphs I wrote... |sites should take action against them if possible. For you to say |that should things should be expected (true) and that there is |nothing you can do about it so it should not bother you when someone |does it is actually part of the problem. You accept it. You tolerate |it. Really? Strange, I never wrote any of what you just interpreted. For instance, why did I write this then?: +With that said, I also will follow-up attempts to get into my firewall from +the outside, and have mailed a number of "desist" messages to users and +their administrators. |So, if someone tries your locks you should do nothing unless they cause |some damage? I think you didn't read what I wrote. | I never said that you should do nothing, because the sad |fact is that you have to, but I did say that people should not view |this as acceptable. Anarchy is not the way to live. Anarchy is what you have to assume, though. To assume that there is anyone else protecting your interests is similar to the security through obscurity fallacy. My purpose in stating what I did was to point out the uselessness of the discussion. None of us are going to react well if someone is trying to break into our system, of that I am pretty sure. However, expecting there to be some authority to enforce our ideas of what is right is simply not realistic, though. Randy Davis Email: randy@megatek.com Corporate Network and System Administrator megatek!randy@uunet.uu.net Megatek Corporation, San Diego, California ucsd!megatek!randy From Firewalls-Owner@GreatCircle.COM Thu Jan 6 02:44:23 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27905; Thu, 6 Jan 94 02:44:23 GMT Received: from post.demon.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27898; Wed, 5 Jan 94 18:44:12 PST Received: from demon.demon.co.uk by post.demon.co.uk id ac04366; 6 Jan 94 2:42 GMT Received: from cellnet.uucp by demon.demon.co.uk id aa11986; 6 Jan 94 2:42 GMT From: Steve Kennedy Message-Id: <26435.9401060136@marvin.gbnet.org> Subject: Re: Opinion requested To: ghost.hac.com!kemasa@gbnet.org Date: Thu, 6 Jan 94 1:36:19 GMT Cc: greatcircle.com!firewalls@gbnet.org, ftp.com!hobbit@gbnet.org, tis.com!mjr@gbnet.org In-Reply-To: <9401051610.AA02844@ghost.hac.com>; from "Kemasa" at Jan 5, 94 8:10 am X-Subliminal-Message: Send large quantities of used bills. X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > >From: mjr@tis.com > >... > >Opinion: > > In a sense, by being on the 'net, one is implicitly permitting > >the world at large to attempt FTP, NFS, SMTP, whatever connections, > >unless you take active steps to prevent it. I also happen to hold > >the (not incompatible view) that you are sole lord and master of your > >internet hookup, and can do anything you like with it, including > >configuring your router to screen off anyone and anything you don't > >like. > > I do not think that you would feel that the same is true in regards to > people checking to see if you left any doors or windows unlocked and > having them enter if you did (house or car or anything else). It is Wrong place ... but anyway ... here in the UK entering someone's premises by an open window/door may be trespass - but there is a seperate crime for 'breaking and entering'. With the Computer Misuse Act it is now an actual offence for you to access computer systems that you are not specifically authorised to do so (and they should display big banners specifying this ...). I don't know if ANYONE has been successfully prosecuted yet ... Steve -- ___ |_ ___ ___ Tel: +44 (0)71 483 1169 Voice (___ | (___) \ / (___) Data: 483 2454 WorldBlazer T3000 PEP+/v32bis... ___) | (___ \/ (___ Data: 483 2455 WorldBlazer T3000 V32bis/PEP+... ISDN: 722 7969/70 Email Snail Mail steve@gbnet.{org,com,net} [home] Steve Kennedy steve@marvin.demon.co.uk [DIS dialup internet] Flat 2, 43 Howitt Rd stevek@cellnet.co.uk [work] London, NW3 4LU From Firewalls-Owner@GreatCircle.COM Thu Jan 6 02:48:16 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27943; Thu, 6 Jan 94 02:48:16 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27935; Wed, 5 Jan 94 18:48:03 PST Message-Id: <9401060248.AA27935@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Wed Jan 5 21:48:16 EST 1994 To: "John B. Brown" Cc: reh@cs.UMD.EDU, firewalls@GreatCircle.COM Subject: Re: Opinion requested Date: Wed, 05 Jan 94 21:48:15 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Your request for a better metaphor is premature. A description of the real thing is adequate. ... Networked file access is here to stay, and even grow. Don't bemoan the attempt to inform. Set your machines to do what you want. The software is all out there on the net, much of it free, and all it takes is spending the time to learn how to use it to do what you want. I rarely contribute more than once to an opinionfest; I generally say all I want to say the first time, and I figure I can do my part to keep the noise down by not making too much of it myself. But I'll make an exception this time, to address the philosophical issues. You say ``set your machines to do what you want''. Would that it were that simple! The fundamental premise of a firewall is that in general, controlling access to a machine is very hard, and therefore that the best solution is to use a limited-capability machine as a choke point. A further premise is that there are things we don't want you -- in the general sense; not you specifically -- to inform yourself about. That is, many organizations have secrets, protection of which is a primary goal of the firewall. In order to keep the firewall secure, we run only services we believe to be inherently secure, at least in the implementation we're running. NFS most certainly does not fit that model, in my opinion; I regard it as a very dangerous service. Networked file access -- by which I assume you mean file system-like access, using the NFS protocol in particular -- may or may not be here to stay -- but not on my firewall. The same goes for anything else we don't trust, such as gopher or http. It isn't that I don't want those services -- I do want them, very much -- but I don't trust the daemons I've seen, for many very specific reasons, and I haven't had the time to fix them. (If indeed they're fixable; I have grave doubts about that, especially for http.) One more component needs to be added to the mix: alarms. I don't assume that our firewall is invulnerable, though we've tried to make it so to the best of our ability. Accordingly, it's very heavily instrumented, to detect attempted attacks. Many others share the same philosophy. The real question--and in fact, the sole original question--is whether or not an attempted NFS operation represents legitimate behavior, as opposed to unethical prying. As I said in my earlier note, I can't give a definitive answer to this, and I wish I could. But it's a fair question to ask, and to dismiss it by saying ``don't bemoan the attempt to inform'', or by saying that one has to expect doorknob-twisting is unfair. Yes, I want people to be well-informed, and I know there will be attempts to break in to our machine -- but the former doesn't mean I have to tell them everything, and the latter doesn't mean that such attempts are proper, simply because they're inevitable. --Steve Bellovin From Firewalls-Owner@GreatCircle.COM Thu Jan 6 04:47:31 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28195; Thu, 6 Jan 94 04:47:31 GMT Received: from muse.microunity.com (muse1.microunity.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28188; Wed, 5 Jan 94 20:47:25 PST Received: from gaea.microunity.com by muse.microunity.com (4.1/ericm1.1) id AA18090; Wed, 5 Jan 94 20:48:52 PST Received: from angst.microunity.com by gaea.microunity.com (4.1/muse1.3) id AA07362; Wed, 5 Jan 94 20:48:56 PST Received: by angst.microunity.com (5.61/muse.mw-2) id AA11507; Wed, 5 Jan 94 20:48:53 -0800 From: ericm@MicroUnity.com (Eric Murray) Message-Id: <9401060448.AA11507@angst.microunity.com> Subject: Opinion digested To: firewalls@GreatCircle.COM Date: Wed, 5 Jan 94 20:48:51 PST X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Now that every single member of the Firewalls list has voiced their opinion as to whether their network is or is not like a house and what sort of activity is legal/ethical, can we please go back to discussing HOW to keep networks secure? There's about 4 newsgroups that this discussion would be appropriate in. Perhaps it can be moved to comp.security.misc? -- ericm ericm@microunity.com From Firewalls-Owner@GreatCircle.COM Wed Jan 5 22:10:58 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28406; Thu, 6 Jan 94 05:55:08 GMT Received: from NEREID.SUNQUEST.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28391; Wed, 5 Jan 94 21:54:56 PST Received: by nereid.sunquest.com (MX V3.3 VAX) id 19666; Wed, 05 Jan 1994 23:02:10 MST Date: Wed, 05 Jan 1994 23:02:08 MST From: Steve Gibbons Reply-To: steve@sunquest.com To: Firewalls@GreatCircle.COM Cc: steve@nereid.sunquest.com Message-Id: <009781A7.5BCA1180.19666@nereid.sunquest.com> Subject: Ack... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Wed, 5 Jan 1994 16:29:44 -0500, "John B. Brown" writes: #> From: kemasa@ghost.hac.com (Kemasa) #> Date: 05 Jan 1994 08:10:21 -0800 (PST) #> Care to give your home address so that people can probe your security #> there? # I don't live in my computer. Neither does anyone else. #Emitting electrons onto a wire at my computer site is NOT the #same as transporting myself to your house. Use something other #than emotion to think with. Hmmm... Perhaps I'm an exception, but... I spend a _great_ deal of time on one computer system or another. Sometimes this amounts to 16+ hours/day connected to the Internet (in some way shape or form.) About half of that time is spent sitting at the console of my home machine (AZTech.Com), so, in a sense an intuder _is_ invading my home. If not my home, then at least a great deal of my life that could be devoted to more pleasant (income-producing) tasks. Such is life, and _that's_ what _real_ security is for (even with network connections.) That said, I see your point, and I think that this entire thread has been far to vociferous for far too long. How about putting the firewall discussions back into the firewalls list, and eliminating all of this recent fluff, eh? -- Steve@Sunquest.COM From Firewalls-Owner@GreatCircle.COM Thu Jan 6 06:12:06 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28460; Thu, 6 Jan 94 06:12:06 GMT Received: from akasha.tic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28447; Wed, 5 Jan 94 22:11:55 PST Received: by akasha.tic.com (5.65/akasha.m4.1.14) id AA16417; Thu, 6 Jan 94 00:13:19 -0600 Date: Thu, 6 Jan 94 00:13:19 -0600 From: erikb@tic.com (Chris Goggans) Message-Id: <9401060613.AA16417@akasha.tic.com> To: firewalls@greatcircle.com Subject: Opinions? Everyone's got one. Cc: erikb@tic.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Here's mine (for the little you may think it's worth): Like it or not, if you have a computer, and it is hooked up to a network (Internet, X.25, or even PSTN) you will eventually be subjected to some kind of intrusion attempt. The Internet is a worst case scenario, since there are so many ways to exploit systems, and so many services that we have all become far to dependant upon to totally abandon that allow some entry into our hosts. It is foolish to say, "But peeking into other's systems is WRONG and unethical.." because noone will subscribe to anyone's code of ethics but their own. Try to force catholicism upon a hindu and see how far you convince him. Anyone who has decided to try to snoop your system has already put aside your feelings and what others perceive as ethical or unethical behavior and is going to accomplish his or her goal regardless. Trust me on this, since I did it for over ten years. If you have not protected yourself, you only have yourself to blame. Like it or not, this world is not an "ethical" place. This is not Walden. This is the Internet. People today get more glee from trading hosts they have patched than they do from trading baseball cards. People could care less about your business, and would love to add "BigNet.Com" to their lists of compromised hosts just for the sole purpose of bragging about it. Or perhaps, they have some other purpose involving your marketing projections or r&d. Or maybe they had a bad day at school and just want to see how long it will take to rm every file on your system. You will get no sympathy from people like CERT or from the FBI or Secret Service You will be told: 1) well, why did you allow anonymous access? Or Why were you exporting that filesystem? That wasn't terribly smart. If you had taken a look at our suggestions, (CERT) this wouldnt have happened. or 2) If it is not a federal interest computer, and crossed state lines, and did not involve a significant dollar amount in damages, then we are not interested. (SS & FBI) Don't believe me? Then ask yourselves why the people who hacked into BARRNet, Sun, Panix, The Well, and scores of other sites around the world are still lose. The authorities have their names. You cannot expect others to treat you with dignity or respect. You can no more question why your internet site has been hacked into than you can ask why you were the one who got mugged in NYC that minute. The only recourse you have is to avoid situations where you have the highest likelyhood of getting attacked, and when possible, fortify yourself against any possible situations. When I speak on computer security, the most important thing I try to drive home to the audience is that they MUST PROTECT THEMSELVES. If you have a modem or any type of network connection, YOU WILL BE HACKED. Period. If you knew that you would be mugged, prior to the mugging, would you take a different route? Would you carry a gun? Or would you still stagger off on your course, waving around wads of cash? This is what we are seeing today on the networks. Companies, like lemmings off a cliff, run to the service providers begging for internet access, without a care in the world. And then once they have been compromised, wonder why the world has dealt them such a poor hand. Protect yourselves, or pull the plug. It really has come to that. ->ME From Firewalls-Owner@GreatCircle.COM Wed Jan 5 22:18:09 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28408; Thu, 6 Jan 94 05:55:09 GMT Received: from ALABAMA.CF.CS.YALE.EDU (RT-GW.CS.YALE.EDU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28392; Wed, 5 Jan 94 21:54:56 PST Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU via SMTP; Thu, 6 Jan 1994 00:51:31 -0500 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.65c/res.client.cf-3.7) id AA20904; Thu, 6 Jan 1994 00:51:30 -0500 Date: Thu, 6 Jan 1994 00:51:30 -0500 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199401060551.AA20904@SPARKY.CF.CS.YALE.EDU> To: jbb@cs.umb.edu, smb@research.att.com Subject: Re: Opinion requested Cc: firewalls@GreatCircle.COM, reh@cs.UMD.EDU Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > ... >firewall. The same goes for anything else we don't trust, such as >gopher or http. It isn't that I don't want those services -- I do want >them, very much -- but I don't trust the daemons I've seen, for many >very specific reasons, and I haven't had the time to fix them. (If >indeed they're fixable; I have grave doubts about that, especially for >http.) The NCSA httpd 1.0 can be run chroot()ed (ie. exec()ed from the /usr/etc/chroot or similar program that does a chroot()). I want all such daemons that can to run chroot()ed before they even being running and after they have done whatever they need to do as root (ie. the initial chroot() and the passive open of their privileged WKS port) they should really do a setuid(NOBODY). Sendmail should do this :-) This should be very secure. At least I know of no way that a chroot()d program can be made to access portions of the filesystem outside of the chroot() hierarchy. And any programs exec()d by the daemon can be caarefully controlled by the admin (ie. by limiting what is put in /bin. should 'sh' be allowed?). Gopher and hybrid-multiprotocol http/gopher (ala gn) servers should be able to be made to work in the same way. You can even have ftpd, httpd as well as gopher and wais daemons share the same hierarchy to chroot() so that they can use the same /bin, /dev, /etc, /usr{/lib,/share} (saving on disk space and reducing redundancy) as well as have them serve the same data files via their different protocols. While I am on the same subject what do you think about the security of having direct public telnet access into a chroot()ed WWW or gopher client app? What is the exposure? I too have real concerns about the security of information (as well as file) systems protocols. I'm interested in hearing more on the subject (Steve - I hope I can coax you into adding your valued opinion at least once more). IMHO servers providing application layer protocol gateways (ie. HTTP<->SQL) and proxy services run the highest vulnerability risk. -Morrow H. Morrow Long, Mgr of Dev., Yale Univ., Comp Sci Dept, 011 AKW, New Haven, CT 06520-8285, VOICE: (203)-432-{1248,1254} FAX: (203)-432-0593 INET: Long-Morrow@CS.Yale.EDU UUCP: yale!Long-Morrow BITNET: Long-Morrow@YaleCS WWW: http://www.cs.yale.edu/HTML/YALE/CS/HyPlans/long-morrow.html From Firewalls-Owner@GreatCircle.COM Thu Jan 6 08:52:19 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28866; Thu, 6 Jan 94 08:52:19 GMT Received: from cs.utexas.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28851; Thu, 6 Jan 94 00:52:03 PST Message-Id: <9401060853.AA06044@cs.utexas.edu> Received: from slip-1-56.ots.utexas.edu by cs.utexas.edu (5.64/1.21/mx-relay) with SMTP id AA06044; Thu, 6 Jan 94 02:53:11 -0600 X-Sender: werner@mailbox.cs.utexas.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Jan 1994 02:53:59 -0600 To: Firewalls@GreatCircle.COM From: werner@cs.utexas.edu (Werner Uhrig) Subject: written not only to evoke a chuckle (Re: Opinion requested) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> From: Karyn Pichnarczyk >> >>> Why does anyone expect people to behave differently on the internet... >> >> Because when the Internet (Arpanet) began, those on it realized it was >> a privilege to have, and treated everyone on the net with respect... a nostalgic view of the past, but more or less correct, I think. >> Now people regard the Internet like they have a RIGHT to access it, >> and treat it with associated carelessness. could it be that only the number but not the percentage of such people is on the increase?!? After all, the net could increase 100-fold but the careless only 10-fold, the net effect might be that things seem 10-times worse to nearly everybody.... In any case, it is not a "NOW" observation either... and who is to say if the percentage is really going up?\ It could be that it is going down... (I'm not sure if the the percentage of government employed users is going up or down... ;-) > From: "John B. Brown" > Date: Wed, 5 Jan 1994 18:08:26 -0500 > > Ah, for the good old days. Now, Delphi sells basic Internet > access for about $250 per year, and the buyers consider they have > bought the right to use the net. That includes anyone. They would > consider the net as just another "super highway" that their taxes > have paid for. And, of course, they are correct. How the computer > professionals respond is appalling, with all the puling and whining > this thread has witnessed. you start out with a correct sentence, and go downhill from there. Just as the Delphi-user's computer was not paid for by taxes (and I have no reason to expect services from it), neither did his taxes pay for each and everything that his "virtual reality" extends to (as a matter of fact, he could be sitting in Timbuktu and not be paying any taxes at all) So the "of course" is only smoke obscuring how incorrect the conclusion that you are leading up to really is. What *IS* appalling is how idiotically clueless (and careless) the powers-that-be seem, allowing every quick-give-me-a-buck snake-oil-salesman "service provider" to cash in by selling "net access" (and put at risk the whole concept?!!) > Mister Jones is right on. The net is now being considered > public property by the public. yep, Joe Public who is trying to make a fast buck by selling access (or even 'value-added access') and Sally Public who is handing $250 to Joe... makes you wonder if someone in the government forgot to do an "environmental impact study"... don't you just love 'em bozos ?!? > PS. Your business is now on a public highway. Act accordingly. yep. I remember when MILnet divorced themselves from "the rest of us". I suspect we will soon see the biggest firewall of them all get created between *.COM and the rest of the world (and people will have to pay an annual fee to retain the *.COM standing, if for no other reason than to get rid of Cracker Joe's PC which registered a *.COM domain name) Next *.GOV will be retreating behind a wall (most who aren't already behind it); then *.EDU will "disappear"... A domain *.PRIVAT will, for a fee (just think how Baby Bell gets to charge you to have an unlisted number), provide "a service"... pretty soon only high-school kids will be roaming the E-highway, government will impose a dress-code, establish a minimum age, and police will ask to see your license and registration (and insurance card?!!)... progress! (what? the Japanese are worried? heh! we are doing a 5th generation scare to them... :-) p.s.: regarding the original question (ah, yes, there was one! :-) > Looking for an nfs mount is no more intrusive than looking for an > anonymous FTP connection. > Now, where do firewallers' opinions tend to align?? "more intrusive"? how do I measure intrusiveness? fewer people are familiar with "NFS service" than "FTP", surely; and it may well be that a higher percentage of NFS-mounts are made by people "not pure at heart"... but "more intrusive"? no, not really, I don't think, not by definition... p.s.: gag me with a spoon, but those analogies flying around sure are tedious and tiringly inappropriate. "Suspect the logic reasoning capabilities of anyone who uses analogies" is my attitude (except when I retreat to using one, of course ;-) Onward through the fog! --- Werner Uhrig From Firewalls-Owner@GreatCircle.COM Thu Jan 6 12:30:28 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29557; Thu, 6 Jan 94 12:30:28 GMT Received: from d.ecc.engr.uky.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29550; Thu, 6 Jan 94 04:30:20 PST Received: from s.ecc.engr.uky.edu by d.ecc.engr.uky.edu (5.59/25-eef) id AA29261; Thu, 6 Jan 94 07:35:47 EST Received: by s.ecc.engr.uky.edu (4.1/SMI-4.1) id AA07243; Thu, 6 Jan 94 07:35:08 EST Date: Thu, 6 Jan 94 07:35:08 EST From: morgan@engr.uky.edu (Wes Morgan) Message-Id: <9401061235.AA07243@s.ecc.engr.uky.edu> To: firewalls@greatcircle.com Subject: Re: Opinion requested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Some archives offer filesystems to NFS just like they offer FTP. I know of exactly *one* such public NFS offering - wuarchive.wustl.edu. If there are other public NFS mounts, they aren't being publicized very well. 8) --Wes From Firewalls-Owner@GreatCircle.COM Thu Jan 6 13:08:08 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29670; Thu, 6 Jan 94 13:08:08 GMT Received: from jupiter.hsi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29663; Thu, 6 Jan 94 05:07:59 PST Received: by jupiter.hsi.com id AA16850 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Thu, 6 Jan 1994 08:09:13 -0500 Date: Thu, 6 Jan 1994 08:09:13 -0500 From: Justus Addiss Message-Id: <199401061309.AA16850@jupiter.hsi.com> In-Reply-To: ericm@microunity.com (Eric Murray) "Opinion digested" (Jan 5, 8:48pm) X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: ericm@microunity.com (Eric Murray), firewalls@greatcircle.com Subject: Re: Opinion digested Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Eric Murray wrote: > > > Now that every single member of the Firewalls list has voiced their > opinion as to whether their network is or is not like a house > and what sort of activity is legal/ethical, can we please go > back to discussing HOW to keep networks secure? > > There's about 4 newsgroups that this discussion would be appropriate in. > Perhaps it can be moved to comp.security.misc? Here here. The signal to noise level has far exceeded the pain threshold. Please let's return to the topic for which this list was created - firewalls. Thank you for your consideration. -- Justus J. Addiss, Sr. Software Engineer 3M HIS addiss@hsi.com, 203-949-6414 From Firewalls-Owner@GreatCircle.COM Thu Jan 6 13:30:36 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29731; Thu, 6 Jan 94 13:30:36 GMT Received: from brandx.cs.ohiou.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29724; Thu, 6 Jan 94 05:30:25 PST Received: by brandx.cs.ohiou.edu (5.59/25-eef) id AA04553; Thu, 6 Jan 94 08:10:50 EST From: C Matthew Curtin Message-Id: <9401061310.AA04553@brandx.cs.ohiou.edu> Subject: Re: Opinion requested To: firewalls@GreatCircle.COM Date: Thu, 6 Jan 94 8:10:48 EST In-Reply-To: <199401060014.AA18376@world.std.com>; from "Bill Heiser" at Jan 5, 94 7:14 pm X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bill Heiser wrote: > "Selden E. Ball, Jr." wrote: > > > A prudent network administrator of a probed site should notify the > > administrator responsible for the system where the probe initiated. > > It is then up to the remote administrator to take approprate action. > > Wouldn't this "notification" quickly turn into a full-time job? > How many "probes" does the typical Internet site receive on a daily > basis anyway? Besides, wouldn't "most" cracker-wannabees spoof their > source addresses anyway? How would you track them down in this case? These are all good questions; this one machine (brandx) is a small 3B2 that is used to provide students studying UNIX with an account that allows them to pretty much do whatever they want. We also use it for development of a MUD. We've never advertised any anonymous FTP service, or anything other than the aforementioned, but I see that I get dozens of anonymous FTP connects here on even the slowest days. There is nothing in our anonymous FTP, yet I see that I get as many as half a dozen connects from the same site right in a row, almost as if someone connects, quits, and connects again for no apparant reason. Every once in a while, I'll get a bit bored and waste some energy trying to find someone who is poking around on my machine. Finding the person resonsible is usually of no value, but it is sometimes entertaining to send someone a talk request from root@brandx and then tell them to knock it off.... :-) In any case, I tend to agree with what seems to be the general consensus here: Poking around for an NFS mount without an invitation is a Bad Thing(tm), but it is ultimately the administrator's responsibility to the owner of the machine to provide a resonable degree of security against such attacks. --- C. Matthew Curtin IEEE Computer Society member Apple II Forever! PO Box 27081 Support Shareware GNO your IIgs! Columbus, OH 43227-0081 cmcurtin@io.org cmc@brandx.cs.ohiou.edu From Firewalls-Owner@GreatCircle.COM Thu Jan 6 07:40:58 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00167; Thu, 6 Jan 94 15:20:13 GMT Received: from akasha.tic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00154; Thu, 6 Jan 94 07:20:03 PST Received: by akasha.tic.com (5.65/akasha.m4.1.14) id AA21259; Thu, 6 Jan 94 09:21:19 -0600 Message-Id: <9401061521.AA21259@akasha.tic.com> To: "John B. Brown" Cc: firewalls@greatcircle.com, hobbit@ftp.com, kemasa@ghost.hac.com, mjr@tis.com, jsq@tic.com Subject: Re: Opinion requested In-Reply-To: Your message of "Wed, 05 Jan 94 16:29:44 EST." <199401052129.AA25376@terminus.cs.umb.edu> Date: Thu, 06 Jan 94 09:21:17 -0600 From: jsq@tic.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I don't live in my computer. Neither does anyone else. Do you live in your office? Your car? No? Are you only alive then, when you are in your house? Or do you just stop living when you use your computer? The problem I see with the analogy of an Internet node as a house is that it is too limiting. The Internet is not a small suburb. It is a diverse subset of the entire world, with homes, businesses, government offices, NGOs, academic institutions, etc. Trivializing it as virtual or a place where nobody lives misses the point. I would log an NFS mount attempt, but I wouldn't contact CERT. For that matter, we log all anonymous FTP transfers; the resulting data makes nice maps. From Firewalls-Owner@GreatCircle.COM Thu Jan 6 07:48:10 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00257; Thu, 6 Jan 94 15:37:26 GMT Received: from npfcds (npfcds.npfc.gov) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00243; Thu, 6 Jan 94 07:37:15 PST Received: from notes_gw.npfc.gov by npfcds (4.1/SMI-4.1) id AA23428; Thu, 6 Jan 94 10:40:04 EST Received: from cc:Mail by notes_gw.npfc.gov (1.30/SMTPLink) id A03286; Thu, 06 Jan 94 10:38:11 EST Date: Thu, 06 Jan 94 10:38:11 EST From: Chuck Mulleady Message-Id: <9401061038.A03286@notes_gw.npfc.gov> To: firewalls@GreatCircle.COM Subject: RE: Opinion Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Text item: RE: Opinion I have to agree with Karyn. The InterNet is a privilege not a right. It is to bad people feel that they have a right. I guess that is society. Chuck mulleady@npfc.gov Network Engineer Synetics From Firewalls-Owner@GreatCircle.COM Thu Jan 6 08:10:59 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00255; Thu, 6 Jan 94 15:37:25 GMT Received: from igi.psc.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00242; Thu, 6 Jan 94 07:37:14 PST Received: by igi.psc.edu (5.65/Ultrix3.0-C 02/11/93 boone) id AA29847; Thu, 6 Jan 1994 10:38:37 -0500 Message-Id: <9401061538.AA29847@igi.psc.edu> To: hobbit@ftp.com (*Hobbit*) Cc: firewalls@greatcircle.com Subject: Re: Opinion requested In-Reply-To: Message from hobbit@ftp.com (*Hobbit*) of "Wed, 05 Jan 94 09:58:12 EST." <9401051456.AA27758@ftp.com> Date: Thu, 06 Jan 94 10:38:36 -0500 From: "Jon 'Iain' Boone" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk hobbit@ftp.com (*Hobbit*) writes: > > I had this exchange with someone recently, after asking him why a machine > under his purview was logged sniffing around our networks: > ... > ============== > Date: Tue, 4 Jan 94 16:12:54 -0500 > From: mib@gnu.ai.mit.edu (Michael I Bushnell) > Subject: Re: mounting.. > > Date: Tue, 04 Jan 1994 14:25:28 EST > From: hobbit@ftp.com (*Hobbit*) > > au contraire. I believe it is valid to assume that anyone trying to NFS-mo unt > our machines is up to no good. Maybe not your machines, but definitely > our machines. > > Looking for an nfs mount is no more intrusive than looking for an > anonymous FTP connection. > > -mib > ============== > > Now, where do firewallers' opinions tend to align?? I would say that the prevalence of anonymous ftp sites makes searching for them "less" intrusive than searching for NFS mounts. It seems a question of willingness to believe that the searcher is of "good intent." If the ftp attempts _only_ tried "anonymous", I would be willing to extend the benefit of the doubt to the searcher. On the other hand, I don't NFS export partitions to the world and would deem anyone looking for them as an intruder. Jon Boone | PSC Networking | boone@psc.edu | (412) 268-6959 finger boone@psc.edu for PGP public key block From Firewalls-Owner@GreatCircle.COM Thu Jan 6 17:45:55 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00879; Thu, 6 Jan 94 17:45:55 GMT Received: from asilomar.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00868; Thu, 6 Jan 94 09:45:47 PST Received: from localhost by asilomar.netcom.com (8.6.4/SMI-4.1) id JAA06803; Thu, 6 Jan 1994 09:50:36 -0800 From: owen@netcom.com (Owen DeLong) Message-Id: <199401061750.JAA06803@asilomar.netcom.com> Subject: Re: Opinion Requested To: firewalls@greatcircle.com Date: Thu, 6 Jan 1994 09:50:35 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1409 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I think I'm starting to see some common beliefs/opinions here. I, myself have gained some clarification of my own opinions on this subject. Here's my current set... Probing an internet site to see if one has public access to a service IS acceptable. This does not include attempts to crack password. It does include attempts to NFS mount directories publicly exported. It does include attempts to connect to ftp as anonymous, guest, or ftp. It does include expn/vrfy SMTP commands. It includes any attempt to access a service from any system up to the point where that system says "NO, go away." in some way such as "Access Denied." It is easy to configure almost any system to do this without using a firewall. Firewalls SHOULD be unnecessary. So should door locks, guns, police, prisons, and many other things we are forced to deal with. Firewalls are an effort by computer users to provide stronger locks on the doors and better security for the data they want to make sure doesn't become public. Firewalls generally will not affect ethical users, as the firewall won't deny anything the ethical user wouldn't have already accepted denial from the regular system. Probing an internet site beyond the first Access Denied for a particular service is unacceptable and unethical. -- Owen DeLong owen@DeLong.SJ.CA.US (Internet) KB6MER@KB6MER.#NOCAL.CA.USA.NA (Amateur Radio Packet) From Firewalls-Owner@GreatCircle.COM Thu Jan 6 18:34:37 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01104; Thu, 6 Jan 94 18:34:37 GMT Received: from ftp.com (babyoil.ftp.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01097; Thu, 6 Jan 94 10:34:28 PST Received: from cucumbers.ftp.com by ftp.com with SMTP id AA05795; Thu, 6 Jan 94 13:35:20 -0500 Message-Id: <9401061835.AA05795@ftp.com> Date: Thu, 06 Jan 1994 13:36:33 EST From: hobbit@ftp.com (*Hobbit*) To: firewalls@greatcircle.com Subject: yow!! Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Well, ya live and learn. I didn't intend to ignite quite that much tinder, but I *did* solicit opinions about something that's probably a political football of a different shape and size at every individual site. I have collected many opinions now, and get the idea. Thanx all... y' can stop.. The overwhelming response, of course, was "they were wrong to probe NFS", but this group is probably heavily biased in that direction -- that's why we're all on this list, eh? Those who don't care don't have any interest in firewalling. Like the FSF. The FSF *has* occasionally been forced to clamp down just a teeny bit in cases of heavy cracking. It does happen. What really surprises me is that it doesn't happen more often, and in really subtle and nasty ways [like dropping backdoors into the socket code in an emacs release, and overwriting all those world-writeable tar or gz files with the changed stuff]. That kind of thing, if done right, would probably go undetected for *months*. But it hasn't happened. Maybe FSF is doing something right after all... _H* From Firewalls-Owner@GreatCircle.COM Thu Jan 6 10:54:07 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01143; Thu, 6 Jan 94 18:44:17 GMT Received: from toe.CS.Berkeley.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01136; Thu, 6 Jan 94 10:44:07 PST Received: from localhost (hartzell@localhost) by toe.CS.Berkeley.EDU (8.6.4/8.1B) id KAA02160; Thu, 6 Jan 1994 10:45:35 -0800 Date: Thu, 6 Jan 1994 10:45:35 -0800 From: George Hartzell Message-Id: <199401061845.KAA02160@toe.CS.Berkeley.EDU> To: firewalls@GreatCircle.COM Subject: gopher and http through firewalls [was "Re: Opinion requested"] In-Reply-To: <199401060551.AA20904@SPARKY.CF.CS.YALE.EDU> References: <199401060551.AA20904@SPARKY.CF.CS.YALE.EDU> Reply-To: hartzell@cs.berkeley.edu (George Hartzell) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk H Morrow Long writes: > > > ... > >firewall. The same goes for anything else we don't trust, such as > >gopher or http. It isn't that I don't want those services -- I do want > >them, very much -- but I don't trust the daemons I've seen, for many > >very specific reasons, and I haven't had the time to fix them. (If > >indeed they're fixable; I have grave doubts about that, especially for > >http.) > > The NCSA httpd 1.0 can be run chroot()ed (ie. exec()ed from the > /usr/etc/chroot or similar program that does a chroot()). > [...] I'm interested in how safely I can let users inside my firewall use gopher and/or mosaic to explore the net, rather than in running a daemon here. I think that there are (or will be soon) "socksified" version of gopher and WWW clients available, but I'm worried about problems in the data that people are browsing. For example, in the commands that people choose to view gif files and what those "gif files" might contain. WWW in particular seems like an opportunity for a more intelligent app. gateway, a la the DEC X app. gateway, that vets the documents before they are passed on, possible rewriting the URL's so that the users's next choice comes back through the gateway. Has this been discussed before on the list? Would anyone whose thought of it like to share their musings? thanks. g. From Firewalls-Owner@GreatCircle.COM Thu Jan 6 20:29:58 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01931; Thu, 6 Jan 94 20:29:58 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01924; Thu, 6 Jan 94 12:29:46 PST Message-Id: <9401062029.AA01924@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu Jan 6 15:29:19 EST 1994 To: long-morrow@CS.YALE.EDU (H Morrow Long) Cc: firewalls@GreatCircle.COM Subject: Security of information protocols Date: Thu, 06 Jan 94 15:29:18 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The NCSA httpd 1.0 can be run chroot()ed (ie. exec()ed from the /usr/etc/chroot or similar program that does a chroot()). I want all such daemons that can to run chroot()ed before they even being running and after they have done whatever they need to do as root (ie. the initial chroot() and the passive open of their privileged WKS port) they should really do a setuid(NOBODY). Sendmail should do this :-) This should be very secure. At least I know of no way that a chroot()d program can be made to access portions of the filesystem outside of the chroot() hierarchy. And any programs exec()d by the daemon can be caarefully controlled by the admin (ie. by limiting what is put in /bin. should 'sh' be allowed?). Gopher and hybrid-multiprotocol http/gopher (ala gn) servers should be able to be made to work in the same way. You can even have ftpd, httpd as well as gopher and wais daemons share the same hierarchy to chroot() so that they can use the same /bin, /dev, /etc, /usr{/lib,/share} (saving on disk space and reducing redundancy) as well as have them serve the same data files via their different protocols. While I am on the same subject what do you think about the security of having direct public telnet access into a chroot()ed WWW or gopher client app? What is the exposure? I too have real concerns about the security of information (as well as file) systems protocols. I'm interested in hearing more on the subject (Steve - I hope I can coax you into adding your valued opinion at least once more). IMHO servers providing application layer protocol gateways (ie. HTTP<->SQL) and proxy services run the highest vulnerability risk. Since the subject has shifted back to technical matters, I'll be glad to throw in a few more comments. (Hey -- I'm not really shy and retiring....) Morrow points out that many of these information daemons can run as chroot. That's good; however, I'm not convinced that it's sufficient. But I need to step back a bit to explain why, in a stronger sense than saying ``here are the particular attacks I'm concerned about''. In an earlier message, Marcus Ranum expressed a preference for strong security mechanisms that aren't aimed at particular attacks. I agree completely. I call that property ``structural security'' -- a fundamental, highly-trusted mechanism that provides certain guarantees. Two examples of this in UNIX systems are the user/group/other file permissions and the chroot() system call. But these two mechanisms are quite limited in what they do. (This type of limitation is probably inherent; something that does too much is probably too complicated for me to trust.) U/G/O says whether or not a given process, with a given uid and (set of) group ids can perform certain operations on specified files. It does not implement complex access modes, such as time dependencies, access to certain parts of files, etc. If you need that, you have to build it yourself -- but that kind of code is tricky. You'd be better off, in some sense, layering your own security on top of U/G/O -- keeping your data in many small files, rather than one large one, or assigning gid's based on login time, or whatever -- but you have to be sure you get that part right. Chroot() -- the mechanism in question here -- provides the user process with a different name space. To the extent that the operations in question are strictly named-based -- and ftp is a good model here -- chroot() provides excellent security. It fails if other operations are possible, as is the case with many information servers, because of the resources that are shared between the chroot()'ed area and the rest of the machine. First, of course, there's the CPU itself. The servers will often execute commands (a point I'll return to below); attacks aimed at getting more CPU cycles (say, for a password cracker) are not impeded by chroot(). If an enemy can upload a program and persuade httpd to execute it, the attack is successful, chroot notwithstanding. More seriously, the chroot() jobs share the same device space and the same network address space. That is, any special files created in the chroot() partition can be used to remount the real disks, tweak the real /dev/kmem, etc. Similarly, network operations will have the real IP address of the machine; packets to 127.0.0.1 will go to the real loopback device, and (in a sense) around the chroot() wall. This can make a mockery of address-based filtering, which is why I don't suggest running these daemons on dual-homed bastion machines. What I'm looking for, I guess, is something closer to a true virtual environment. It would be lovely if I could assign a new IP address to httpd and gopherd, or if I could remap or restrict how cdevsw and bdevsw were interpreted. Those are some of the primitives I'd like to see to provide the kind of assurance I want for information daemons. I stress execution because, to a large extent, that's what these daemons do. To the extent that they're simply a prettier way to do ftp's, they're harmless. They're also much less interesting. The http folks here at Bell Labs claim that most of the interesting uses for the technology involve running shell or perl scripts to process user queries. That scares me -- I don't want such powerful interpreters available at all in the restricted area. Worse yet, the scripts themselves are then the network daemons, with all that implies for how they should be written. But they're not written with that much care, in general, because they're not written by folks for whom security is the primary concern. Can these scripts be tricked? My guess is that they can be, though I don't know for sure. (I'm further hindered when it comes to httpd, since the available documentation seems to be available solely as a hypertext -- which is a cute trick, but an unpleasant way to audit a system's configuration instructions, since I'm never sure that I've read the whole thing, and hence that I've seen and understood all of the squirrelly little configuration options.) I don't know how to solve this one. Bill Cheswick, Dave Korn, and I are looking into the question. I'd like to know what sorts of things one should do to the shell -- or to some other interpreter -- so that sufficient power remains to do interesting things, while blocking attempts at subversion. In other words, what can one do to provide structural security for the shell. Call it a research problem (i.e., I don't know the answer). (Btw -- for those who are about to object that the shell is just too huge and powerful: you may be right, but some power, at least, is needed, or we'll end up with C programs that are equally insecure.) I'll save the question of client-side security for another time, save to note that many of the risks are also present in MIME mail. See RFC 1521 for a detailed analysis of some of the dangers. --Steve Bellovin From Firewalls-Owner@GreatCircle.COM Thu Jan 6 22:04:44 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02499; Thu, 6 Jan 94 22:04:44 GMT Received: from hawkwind.utcs.toronto.edu (hawkwind.utcs.utoronto.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02492; Thu, 6 Jan 94 14:04:34 PST Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <24071>; Thu, 6 Jan 1994 17:05:46 -0500 To: firewalls@GreatCircle.COM Subject: Re: Opinion requested In-Reply-To: jbb's message of Wed, 05 Jan 1994 17:13:29 -0500. <199401052213.AA25782@terminus.cs.umb.edu> Date: Thu, 6 Jan 1994 17:05:30 -0500 From: Chris Siebenmann Message-Id: <94Jan6.170546est.24071@hawkwind.utcs.toronto.edu> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I don't log NFS showmount requests (although I could); I don't really consider them anything rude in general. I do log NFS mount attempts, and generally consider outside ones at least doorknob rattling, unless they're going for something that clearly seems to be public. I'll pass on the morality issue. I'm just interested in NFS mount attempts as an indication of intrusion attempts in progress. - cks [to make this vaguely useful: I can mail my patches to do this (for Ultrix 4.2a's mountd) to interested parties. Response to this offer may be slow.] From Firewalls-Owner@GreatCircle.COM Thu Jan 6 22:17:41 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02547; Thu, 6 Jan 94 22:17:41 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02540; Thu, 6 Jan 94 14:17:28 PST Received: from West.Sun.COM (west.West.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA04716; Thu, 6 Jan 94 14:18:25 PST Received: from maui.West.Sun.COM by West.Sun.COM (4.1/SMI-4.1) id AA09930; Thu, 6 Jan 94 14:18:33 PST Received: from twiddle.West.Sun.COM by maui.West.Sun.COM (4.1/SMI-4.1) id AA18074; Thu, 6 Jan 94 14:18:31 PST Received: by twiddle.West.Sun.COM (5.0/SMI-SVR4) id AA01016; Thu, 6 Jan 1994 14:18:39 +0800 Date: Thu, 6 Jan 1994 14:18:39 +0800 From: Paul.Danielson@West.Sun.COM (Paul Danielson) Message-Id: <9401062218.AA01016@twiddle.West.Sun.COM> To: firewalls@GreatCircle.COM Subject: Re: yow!! X-Sun-Charset: US-ASCII Content-Length: 1237 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hobbit writes: > "What really surprises me is > that it doesn't happen more often, and in really subtle and nasty ways > [like dropping backdoors into the socket code in an emacs release, and > overwriting all those world-writeable tar or gz files with the changed > stuff]. That kind of thing, if done right, would probably go undetected > for *months*. > But it hasn't happened. Maybe FSF is doing something right after all..." The other alternative is that nobody has noticed the changes. If someone is creative enough to make subtle changes to a release, they just might be smart enough to keep quite about it, and only use the "back doors" occasionally. I remember a discussion about how to determine if a C compiler had been hacked such that it detected when it was compiling either a C compiler or "login" and changed the resulting binaries. The consensus was that, done correctly, it would be almost impossible to identify the changes, or that your "login" program had been compromised. Unless I have read every line of code, and understood what it does, I don't compile source from outside agents. I just ignore code repositories, like FSF, that don't properly protect their products. Paul My opinions! Mine! Mine! Mine! From Firewalls-Owner@GreatCircle.COM Thu Jan 6 22:33:40 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02605; Thu, 6 Jan 94 22:33:40 GMT Received: from ALABAMA.CF.CS.YALE.EDU (RT-GW.CS.YALE.EDU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02598; Thu, 6 Jan 94 14:33:32 PST Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU via SMTP; Thu, 6 Jan 1994 17:34:57 -0500 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.65c/res.client.cf-3.7) id AA24232; Thu, 6 Jan 1994 17:34:56 -0500 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199401062234.AA24232@SPARKY.CF.CS.YALE.EDU> To: smb@research.att.com Cc: firewalls@GreatCircle.COM Subject: Re: Security of information protocols In-Reply-To: Your message of Thu, 06 Jan 94 15:29:18 EST. Date: Thu, 06 Jan 94 17:34:55 -0500 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9401062029.AA01924@mycroft.GreatCircle.COM> smb@research.att.com (Steve Bellovin) writes: >What I'm looking for, I guess, is something closer to a true virtual >environment. It would be lovely if I could assign a new IP address >to httpd and gopherd, or if I could remap or restrict how cdevsw and >bdevsw were interpreted. Those are some of the primitives I'd like >to see to provide the kind of assurance I want for information daemons. I presume that a Mac, Windows or (gasp!) DOS HTTP or Gopher server would be fairly secure then (more than a Unix box) as long as the Mac or PC : o resided in the DMZ o didn't mount any other local hosts disks o wasn't trusted in any way by other local hosts o was only being used to serve files (ie. was a pure file server and did not perform script execution) This would suffice as long as you just want to serve whole files (text, rich text, images, audio, video, etc.) but didn't need script nor app gateway capabilities. - Morrow From Firewalls-Owner@GreatCircle.COM Thu Jan 6 14:40:58 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02613; Thu, 6 Jan 94 22:34:21 GMT Received: from iphase.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02606; Thu, 6 Jan 94 14:34:12 PST Received: from chip.iphase.com by iphase.com (4.1/1.34) id AA20744; Thu, 6 Jan 94 16:35:33 CST Received: by chip.iphase.com (4.1/SMI-4.1-Goofy) id AA14700; Thu, 6 Jan 94 16:35:32 CST From: plarkin@iphase.com (Patrick Larkin Jr) Message-Id: <9401062235.AA14700@chip.iphase.com> Subject: I too need Opinions To: firewalls@greatcircle.com Date: Thu, 6 Jan 1994 16:35:31 -0600 (CST) Reply-To: plarkin@iphase.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1118 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Currently, we only allow users in our company to connect to external sites from Secured systems only. By that, I mean systems that are maintained by MIS according to some predefined "rules of engagement". Now we have some people who would like to be able to connect to other internet sites from such things as Lab systems (where 100 employees know root's pw) to PCs/MACs at home (who have slip connections to our net). Something about giving "unchecked" access to the Internet just doesnt feel right to me. Am I being prudent or simply "Self appointed Internet Guardian". Either way you see it, tell me why. What are other company's takes on this issue? Thanks, -- +=======================================================================+ | PATRICK H LARKIN, JR. - System Administrator, Interphase Corp, Dallas | |>---------------------------------------------------------------------<| | "Remember 'Rock Climbing'? Now we have 'Hypno-Helio-Static-Stasis'!" | | -- Dr. Clayton Forrester, Deep 13 - MST 3000 | \_____________________________________________________________________/ From Firewalls-Owner@GreatCircle.COM Thu Jan 6 22:50:45 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02660; Thu, 6 Jan 94 22:50:45 GMT Received: from mail.uunet.ca (uunet.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02653; Thu, 6 Jan 94 14:50:38 PST Received: from jtsv16 by mail.uunet.ca with UUCP id <58624(6)>; Thu, 6 Jan 1994 17:42:00 -0500 Received: by jts.com (/\==/\ Smail3.1.25.1 #25.17) id ; Thu, 6 Jan 94 16:20 EST Received: by lemon.jts.com (4.1/SMI-4.1) id AA11848; Thu, 6 Jan 94 16:20:45 EST From: jimc@jts.com Message-Id: <9401062120.AA11848@lemon.jts.com> Subject: Q re: WWW, mosaic, http To: firewalls@GreatCircle.COM Date: Thu, 6 Jan 1994 16:20:43 -0500 Reply-To: jimc@jts.com Organization: JTS Computer Systems Ltd., Toronto, Canada X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 176 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk What are WWW, mosaic and http? -- Jim Carroll | JTS Computer Systems Ltd. | The ongoing struggle of jimc@jts.com | Toronto, Ontario | Prometheus vs. Epimetheus.... From Firewalls-Owner@GreatCircle.COM Fri Jan 7 00:16:47 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02938; Fri, 7 Jan 94 00:16:47 GMT Received: from bluejay.creighton.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02931; Thu, 6 Jan 94 16:16:31 PST Received: by bluejay.creighton.edu (1.37.109.4/16.2) id AA29093; Thu, 6 Jan 94 18:16:15 -0600 Date: Thu, 6 Jan 1994 18:16:14 -0500 (CDT) From: Chuck Buda Subject: Re: Q re: WWW, mosaic, http To: jimc@jts.com Cc: firewalls@GreatCircle.COM In-Reply-To: <9401062120.AA11848@lemon.jts.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Thu, 6 Jan 1994 jimc@jts.com wrote: > What are WWW, mosaic and http? > > -- > Jim Carroll | JTS Computer Systems Ltd. | The ongoing struggle of > jimc@jts.com | Toronto, Ontario | Prometheus vs. Epimetheus.... > WWW stand for the World Wide Web. It's a wide area hypermedia information retrieval system (What a mouthful!). Basically, through hypertext hooks, you can access information on WWW machines without a system account. Http is the Hypertext Transfer Protocol that accomplishes this feat. Mosaic (from NCSA) is a Windows (and XWindows, I think) program that allows you to access all aspects of hypermedia (REAL NEAT!!!). For more info, telnet to info.cern.ch. This is the High Energy Particle Physics Center (in Switzerland) that started it all! *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* * * * Chuck Buda (cbuda@creighton.edu) * * Unix System(s) Administrator also * * Network Operations Manager ( (cbuda@cu (in JAYNet))* * Creighton University Computer Center * * 2500 California St. Phone: (402) 280-2260 * * Omaha NE 68178-0002 FAX : (402) 280-2573 * * * * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * * * * "Practice random acts of kindness and senseless beauty" * * * * ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ * * * * "Of all men's miseries the bitterest is this, to know so * * much and have control over nothing." * * * * Herodotus (484-432 B.C.) * *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From Firewalls-Owner@GreatCircle.COM Fri Jan 7 00:43:35 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03029; Fri, 7 Jan 94 00:43:35 GMT Received: from hermes.intel.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03022; Thu, 6 Jan 94 16:43:25 PST Received: from argus.intel.com by hermes.intel.com (5.65/10.0i); Thu, 6 Jan 94 16:44:50 -0800 Received: by argus.intel.com (5.65/10.0i); Thu, 6 Jan 94 16:44:49 -0800 From: sedayao@argus.intel.com (Jeffrey C. Sedayao) Message-Id: <9401070044.AA10816@argus.intel.com> Subject: Re: I too need Opinions To: plarkin@iphase.com Date: Thu, 6 Jan 94 16:44:49 PST Cc: firewalls@GreatCircle.COM In-Reply-To: <9401062235.AA14700@chip.iphase.com> from "Patrick Larkin Jr" at Jan 6, 94 04:35:31 pm X-Mailer: ELM [version 2.4dev PL66] Mime-Version: 1.0 Content-Type: text Content-Length: 2321 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Currently, we only allow users in our company to connect to external > sites from Secured systems only. By that, I mean systems that are maintained > by MIS according to some predefined "rules of engagement". > Now we have some people who would like to be able to connect to > other internet sites from such things as Lab systems (where 100 > employees know root's pw) to PCs/MACs at home (who have slip connections > to our net). > Something about giving "unchecked" access to the Internet just doesnt > feel right to me. Am I being prudent or simply "Self appointed Internet > Guardian". Either way you see it, tell me why. What are other > company's takes on this issue? IMHO, you are being prudent. You want to have some way to track down your own employees when they do things they shouldn't. When you get one of those "someone from your company has been trying to break into our site" calls, you need to be ready to determine the validity of the claim. If you let anyone anywhere out, one of your employees (or contractors) could pop a PC on the network, do some nastiness, and then just disappear. With "unchecked" access, you may find that your users may put holes in your firewalls. If you let everyone everywhere do FTP out, the first thing that some users will do is put telnet on a port > 1023 so they can "conveniently" log into their own machine from the Internet. They may put other things up in those ports, like a tcp relaying program. I have seen both of these things happen. At Intel, we try (although we don't always succeed) to limit access to certain machines and subnets. We are looking at proxy services like socks but are worried about authenticating users on the client systems (please don't turn this into a ident discussion). > Thanks, > -- > +=======================================================================+ > | PATRICK H LARKIN, JR. - System Administrator, Interphase Corp, Dallas | > |>---------------------------------------------------------------------<| > | "Remember 'Rock Climbing'? Now we have 'Hypno-Helio-Static-Stasis'!" | > | -- Dr. Clayton Forrester, Deep 13 - MST 3000 | > \_____________________________________________________________________/ > -- Jeff Sedayao Intel Corporation sedayao@argus.intel.com From Firewalls-Owner@GreatCircle.COM Fri Jan 7 01:40:28 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03204; Fri, 7 Jan 94 01:40:28 GMT Received: from catalyst.math.ufl.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03197; Thu, 6 Jan 94 17:40:21 PST From: bb@math.ufl.edu Received: by catalyst.math.ufl.edu (4.1/4.03) id AA03099; Thu, 6 Jan 94 20:41:46 EST Date: Thu, 6 Jan 94 20:41:46 EST Message-Id: <9401070141.AA03099@catalyst.math.ufl.edu> To: firewalls@GreatCircle.COM Subject: SunOS 4.x chroot(2) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Long-Morrow@CS.Yale.EDU writes: > At least I know of no way that a chroot()d program can be made to > access portions of the filesystem outside of the chroot() hierarchy. Those of you with SunOS 4.x should do a 'man 2 fchroot' and read about the system call that takes a file descriptor opened on the original root directory and reverses the effects of chroot(2). Another member of the League for Programming Freedom (LPF) lpf@uunet.uu.net ------------------------------------------------------------------------------- Brian Bartholomew - bb@math.ufl.edu - EX-Univ. of Florida Dept. of Mathematics From Firewalls-Owner@GreatCircle.COM Fri Jan 7 02:03:15 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03271; Fri, 7 Jan 94 02:03:15 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03264; Thu, 6 Jan 94 18:03:08 PST Received: by relay.tis.com; id AA07750; Thu, 6 Jan 94 21:04:16 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma007743; Thu Jan 6 21:03:42 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA28547; Thu, 6 Jan 94 21:03:41 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA08545; Thu, 6 Jan 94 21:03:40 EST Date: Thu, 6 Jan 94 21:03:40 EST From: mjr@tis.com Message-Id: <9401070203.AA08545@otter.tis.com> To: bb@math.ufl.edu, firewalls@GreatCircle.COM Subject: Re: SunOS 4.x chroot(2) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Those of you with SunOS 4.x should do a 'man 2 fchroot' and read about >the system call that takes a file descriptor opened on the original >root directory and reverses the effects of chroot(2). If you really care, you can noop out the entry for fchroot in the system call table (for Suns, that's /sys/os/init_sysent.c) I'm not overly concerned about the threat of someone fchrooting out of a chrooted area on one of my systems, since in order to do it, they'd need to create an executable that exploited the fchroot, and invoke it. Generally, it's the case with a chrooted area that you also put some restrictions on the permissions of the area, to prevent folks from creating arbitrary executables, and, finally, you need privs to execute the call. You'd need a pretty sloppily set up FTP area to take advantage of fchroot, I think. mjr. From Firewalls-Owner@GreatCircle.COM Fri Jan 7 11:11:25 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04685; Fri, 7 Jan 94 11:11:25 GMT Received: from firewall.mc.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04678; Fri, 7 Jan 94 03:11:14 PST Received: from jericho.mc.com by firewall.mc.com with SMTP id AA18399 (5.65c/IDA-1.4.4 for ); Fri, 7 Jan 1994 06:12:28 -0500 Received: from darkstar by jericho.mc.com (4.1/1.34/indent-1.0 for mc.com) id AA10415; Fri, 7 Jan 94 06:12:27 EST From: blu@jericho.mc.com (Brian Utterback) Received: by darkstar (4.1//ident-1.0) id AA21675; Fri, 7 Jan 94 06:12:25 EST Date: Fri, 7 Jan 94 06:12:25 EST Message-Id: <9401071112.AA21675@darkstar> To: bb@math.ufl.edu Subject: Re: SunOS 4.x chroot(2) Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk After reading the man page, my opinion about chroot has not changed. Chroot does not create some "virtual world" in which a process executes. All it does is change the interpretation of the file name during an open call. Just like setuid programs, there are certain things you need to do to be secure. Like closing all the file descriptors other than stdin, stdout, stderr and any others that are absolutely necessary. Do not, under any circumstances, leave open a file descriptor pointing to /. Chroot is not magic. Used properly it is very secure, but it can only ever be as secure as the code in the kernel and your understanding of the call itself. 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 You can't grep dead trees. From Firewalls-Owner@GreatCircle.COM Fri Jan 7 12:39:02 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04909; Fri, 7 Jan 94 12:39:02 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04902; Fri, 7 Jan 94 04:38:55 PST Message-Id: <9401071238.AA04902@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Fri Jan 7 07:39:23 EST 1994 To: blu@jericho.mc.com (Brian Utterback) Cc: bb@math.ufl.edu, firewalls@GreatCircle.COM Subject: Re: SunOS 4.x chroot(2) Date: Fri, 07 Jan 94 07:39:23 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk After reading the man page, my opinion about chroot has not changed. Chroot does not create some "virtual world" in which a process executes. All it does is change the interpretation of the file name during an open call. Just like setuid programs, there are certain things you need to do to be secure. Like closing all the file descriptors other than stdin, stdout, stderr and any others that are absolutely necessary. Do not, under any circumstances, leave open a file descriptor pointing to /. Chroot is not magic. Used properly it is very secure, but it can only ever be as secure as the code in the kernel and your understanding of the call itself. Absolutely right. I'd also direct folks' attention to fchdir(). The saving grace is that most programs don't open directories, and in particular don't open / -- but I've seen the latter done sometimes, to place some ``harmless'' file on fd 0, 1, and 2. (The rationale I've heard for not using /dev/null is that the latter isn't guaranteed to be there, and -- while one cannot write, nor on some machines read, a directory -- most UNIX programs never check error returns on read/write anyway...) From Firewalls-Owner@GreatCircle.COM Fri Jan 7 13:12:50 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05015; Fri, 7 Jan 94 13:12:50 GMT Received: from mail-relay (mail-relay.olsen.ch) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05007; Fri, 7 Jan 94 05:12:36 PST Received: from rouble.olsen.ch by mail-relay with smtp (Smail3.1.28.1 #7) id m0pIH1x-0003TmC; Fri, 7 Jan 94 14:15 MET Received: by rouble.olsen.ch (4.1/SMI-4.1) id AA26564; Fri, 7 Jan 94 14:14:00 +0100 Date: Fri, 7 Jan 94 14:14:00 +0100 From: nagler@olsen.ch (Rob Nagler) Message-Id: <9401071314.AA26564@rouble.olsen.ch> To: Firewalls@GreatCircle.COM Subject: MIME questions Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk smb@research.att.com writes: > I'll save the question of client-side security for another time, save > to note that many of the risks are also present in MIME mail. See > RFC 1521 for a detailed analysis of some of the dangers. This is a very interesting topic (more interesting than how mjr protects his house ;-). As MIME UAs become more prevalent, I see a proliferation of mail-viri. Mailers will then need to be retrofitted with automatic virus detectors (as some PCs come with today?). But how will these work? How can you verify that every application attachment is clean? Most users will just click their "run this attachment as a perl script" button and there goes your system. (Digital signatures are a good prevantative measure, but I don't think this will eliminate all viri.) We have a hard enough time teaching users and sysadmins to pick good passwords (and not to e-mail them!). The attachment problem seems an order of magnitude more complicated in terms of user education imho. This is why I think mail-virus detectors will have to be automatic. In a similar vein, I'm amazed I haven't heard of a postscript virus. I download lots of files and print them without having a clue if some global printer parameter isn't being messed with. From Firewalls-Owner@GreatCircle.COM Fri Jan 7 14:22:05 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05221; Fri, 7 Jan 94 14:22:05 GMT Received: from akasha.tic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05214; Fri, 7 Jan 94 06:21:57 PST Received: from xfrsparc.tic.com by akasha.tic.com (5.65/akasha.m4.1.14) id AA10711; Fri, 7 Jan 94 08:23:19 -0600 Received: by xfrsparc.tic.com (5.65/sub.1.6) id AA18265; Fri, 7 Jan 94 08:23:18 -0600 Message-Id: <9401071423.AA18265@xfrsparc.tic.com> To: Firewalls@greatcircle.com Subject: Re: MIME questions In-Reply-To: Your message of "Fri, 07 Jan 94 14:14:00 +0100." <9401071314.AA26564@rouble.olsen.ch> Date: Fri, 07 Jan 94 08:23:17 -0600 From: smoot@tic.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >nagler@olson.ch writes: >In a similar vein, I'm amazed I haven't heard of a postscript virus. >I download lots of files and print them without having a clue if some >global printer parameter isn't being messed with. PostScript is a potentially bad hole. You can manipulate files with the language. This is especially bad when you preview files on a workstation. Smoot Carl-Mitchell Texas Internet Consulting 1106 Clayton Lane, Suite 500W Austin, TX 78723 +1 512 451-6176 From Firewalls-Owner@GreatCircle.COM Fri Jan 7 14:33:30 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05259; Fri, 7 Jan 94 14:33:30 GMT Received: from relay1.pipex.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05252; Fri, 7 Jan 94 06:33:21 PST Received: from gw.aea.orgn.uk by relay1.pipex.net with SMTP (PP) id <28275-0@relay1.pipex.net>; Fri, 7 Jan 1994 14:33:23 +0000 Received: from jlines.harwell.aea.orgn.uk by aea.orgn.uk (4.1/SMI-4.1) id AA20541; Fri, 7 Jan 94 14:30:44 GMT Received: by jlines.harwell.aea.orgn.uk (4.1/SMI-4.1) id AA16846; Fri, 7 Jan 94 14:36:25 GMT Date: Fri, 7 Jan 94 14:36:25 GMT From: john.lines@aea.orgn.uk (John Lines) Message-Id: <9401071436.AA16846@jlines.harwell.aea.orgn.uk> To: Remy.Giraud@meteo.fr Subject: packet logging on NSC routers Cc: dotytr@nscultrix2.network.com, firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Remy.Giraud@meteo.fr writes : > We are customer from Network System router because of their filtering > capacity. Yes, Marcus you can do what is describe above. > You are connected to your T1 via serial 0 you can apply on that > interface saying "discard all packets having x.x.*.* source addresses" > And of course you don't apply that filter and your ethernet 0 if > it's that interface on your network. > In the Network System router you have 5 (!) points of filtering : > - incoming = all packets getting in your router whatever the interface > - input packet on each interface > - inside the router ( eg. discard that packet if the next gateway > after a look at the routing table is x.x.x.x ) > - output packet on each interface > - outgoing = all packets getting out of your router whatever the > interface > And all the packet coming through the router either discarded or not > may be copyied to a logging host. ___________________________ > Hope this helps > Remy > We use an NSC router and would like to be able to look at packets which fail some of our filters. Have you implemented a program which picks up packets from the 'copy_to' filter action, and if so would you be willing to let me have a copy. This has been on my things to do list for a while, but if it has already been done then this would save reinventing the wheel. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - John Lines Internet: john.lines@aea.orgn.uk AEA, 8.9 Harwell, Didcot Local: lines@jlines.harwell Oxfordshire, OX11 0RA, U.K. Phone: +44 235 432258 FAX: +44 235 432339 Decnet: harx::ccgjli - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please note that any views expressed here do not necessarily reflect the views or policies of AEA. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From Firewalls-Owner@GreatCircle.COM Fri Jan 7 07:18:14 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05335; Fri, 7 Jan 94 15:05:40 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05328; Fri, 7 Jan 94 07:05:30 PST Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA17795; Fri, 7 Jan 94 10:01:10 -0500 Received: by cobalt.house.gov (AA04514); Fri, 7 Jan 94 10:07:13 -0800 Date: Fri, 7 Jan 94 10:07:13 -0800 From: Dorian Deane Message-Id: <9401071807.AA04514@cobalt.house.gov> To: bb@math.ufl.edu, firewalls@GreatCircle.COM, mjr@tis.com Subject: Re: SunOS 4.x chroot(2) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I'm not overly concerned about the threat of someone > fchrooting out of a chrooted area on one of my systems, since > in order to do it, they'd need to create an executable that > exploited the fchroot, and invoke it. Generally, it's the case > with a chrooted area that you also put some restrictions on > the permissions of the area, to prevent folks from creating > arbitrary executables, and, finally, you need privs to execute > the call. You'd need a pretty sloppily set up FTP area to > take advantage of fchroot, I think. > > mjr. > I wonder if fchroot would be a good candidate for an idea of mine: I've long wondered how useful it would be to make a source code checker that looks for obvious signs of badness. I know it would be incomplete almost by definition, but imagine a script that greps all source in a tree for references to mail, sendmail, /etc/passwd, etcetera, and now, perhaps fchroot. Obviously it takes a human eye to decide if the usage is legit or not, but those entries could at least be highlighted. Of course, for those who read _all_ source code, this wouldn't buy anything. Does this seem like a worthwhile idea to anyone? If so, what would you include? Also, I'm well aware that the greatest danger would be for someone to ignorantly rely on such a checker and believe that their software was safe because no statements were flagged. dorian From Firewalls-Owner@GreatCircle.COM Fri Jan 7 16:01:12 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05516; Fri, 7 Jan 94 16:01:12 GMT Received: from p-o.ans.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05509; Fri, 7 Jan 94 08:01:03 PST Received: by p-o.ans.net id AA04777 (5.65c/IDA-1.4.4 for Firewalls mailing list ); Fri, 7 Jan 1994 10:56:27 -0500 Message-Id: <199401071556.AA04777@p-o.ans.net> Date: Fri, 7 Jan 94 09:53:50 EST From: "Andrew T. Robinson" To: Firewalls mailing list Subject: Data security Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This message was recently posted to the HSPNET-L discussion. I am interested to hear the responses from the Firewalls folks. ----------------------------- Note follows ----------------------------- Message-Id: <199401071338.AA15621@p-o.ans.net> Date: Fri, 7 Jan 1994 08:42:22 -0500 Reply-To: Hospital Computer Network Discussion Group and Data Base Sender: Hospital Computer Network Discussion Group and Data Base From: Hannah King Subject: Data security To: "Andrew T. Robinson" Sean maintains that "the Internet is as secure or insecure as you would like it to be" and that anyone who tells us different is misinformed. I would like to see Sean document is assertion. Network insecurity keeps many corporations off the Internet. Viruses and worms are encountered on an almost daily basis in college computers transferring files over the Internet. Stoll's _Cuckoo's Nest_ depicts a fairly typical event. Teenage hackers have broken into banks and credit card company computers -- using the networks. The lack of any comprehensive and coordinated federal, state, and local legislation regulating the use of and accessibiltiy to network-based information is further cause for concern. What consequences face a person who reads, even out of curiosity, someone elese's medical records? How can we be sure that the protections for print based records -- single line through a mistake, signatures, ink, no erasures -- can be transferred to electronic systems? Electronic records can be more easily modified than photos re-touched. Here in Syracuse a woman who was poisoning her daughter worked in the hospital lab and falsified her daughter's records to hide test results. I've heard that calling up a friend's, enemy's, or neighbor's records on the unit computer is not considered unusual. How protected are the computers on hospital floors where you all work? Could someone someday modify doctors' orders to harm someone? Who's going to re-tool medical records clerks to encrypt and de-code medical records? Finally, a data encrypton standard has yet to be identified by national or international standards bodies. Arguments about whether the FBI/CIA should control encrypton techniques, applications, and access standards setting are a major barrier to setting encrypton standards. Hannah King SUNY HSC Library at Syracuse kingh@snysyrv1 kingh@vax.cs.hscsyr.edu 766 Irving Avenue Syracuse, NY 13210 315-464-7109 315-464-7199 (fax) From Firewalls-Owner@GreatCircle.COM Fri Jan 7 16:31:55 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05696; Fri, 7 Jan 94 16:31:55 GMT Received: from asilomar.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05689; Fri, 7 Jan 94 08:31:48 PST Received: from localhost by asilomar.netcom.com (8.6.4/SMI-4.1) id IAA07045; Fri, 7 Jan 1994 08:36:42 -0800 From: owen@netcom.com (Owen DeLong) Message-Id: <199401071636.IAA07045@asilomar.netcom.com> Subject: Net Access, privilege or right? To: firewalls@greatcircle.com Date: Fri, 7 Jan 1994 08:36:41 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1183 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Net access was once a privilege. I don't think this is true any more. However, many of us have been working very hard at this. Making the net available to everyone has been a long-term goal of many of the people who helped construct it. We are pretty much there and we are starting to finally experience some of the sociological implications of this. We are also starting to experience some scalability issues relating to the number of users this implies. The net is scaling up. Things are growing very rapidly. With rapid growth come growing pains. However, I wouldn't go so far as to say that net access is currently a right. I think that it is a right with responsibilities attached, and that should one fail to meet those responsibilities, ones right can, at least in this case, be revoked. The responsibilities are to use the net in a manner consistent with the laws and policies of the internet. I think that this includes an acceptance of it being "OK" to try to NFS mount or ftp or telnet to any machine on the net. On the other hand, I think that any sort of a GO AWAY from that machine should also mean that you don't try harder to get around the denial. Owen From Firewalls-Owner@GreatCircle.COM Fri Jan 7 08:40:59 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05608; Fri, 7 Jan 94 16:24:44 GMT Received: from deshaw.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05598; Fri, 7 Jan 94 08:24:24 PST Received: from cs2.deshaw.com by deshaw.com with SMTP id AA05741 (5.65c/IDA-1.4.4 for ); Fri, 7 Jan 1994 11:25:44 -0500 Message-Id: <199401071625.AA05741@deshaw.com> To: firewalls@greatcircle.com Subject: Re: yow!! (trapdoors) Date: Fri, 07 Jan 94 11:25:44 -0500 From: Mark Moraes Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk One annoyance that I look for (and redirect) in software off the net is the damn option to email bug reports to the developers. Even if it's not a trapdoor, the environment information in the bug reports can be a security leak. Mark. From Firewalls-Owner@GreatCircle.COM Fri Jan 7 08:48:14 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05625; Fri, 7 Jan 94 16:25:48 GMT Received: from muddy.huber.com (huber.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05618; Fri, 7 Jan 94 08:25:38 PST Received: from marley.huber.com by muddy.huber.com with SMTP id AA12565 (5.65c/IDA-1.4.4 for ); Fri, 7 Jan 1994 11:20:30 -0500 Received: from smtpgwy.huber.com by marley.huber.com with SMTP id AA131561 (5.65c/IDA-1.4.4 for ); Fri, 7 Jan 1994 11:23:17 -0500 Received: from ccMail by smtpgwy.huber.com id AA757957390 Fri, 07 Jan 94 07:43:10 CST Date: Fri, 07 Jan 94 07:43:10 CST From: gscheitl@huber.com Encoding: 1170 Text Message-Id: <9400077579.AA757957390@smtpgwy.huber.com> To: firewalls@greatcircle.com Subject: SOCKS - DOS? Windows Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, I'm new to this game of Internet and Firewalls - I've only been in the arena for about a month, but I have a question. First, let me describe the system that I have to use to access the Net. What I do is use LANworkplace for DOS to login in to a local SUN system. Then, from the SUN I can rtelnet and rftp out the firewall that is using SOCKS Protocol 4.0. This is the way our MIS group set up the system, I have no control over this. What would be nice is to go through the SOCKS Firewall directly from DOS or Windows. So here's my question: Is there any way I can access the SOCKS firewall directly from DOS or Windows without having to go through the SUN and a UNIX environment? All responses will be appreciated, but please remember that I am a novice at firewalls, so try to keep them simple. Gerard | My opinion, nobody else's opinion but my gscheitl@huber.com | my own. Remember, chaos in life is a necessary evil, for without it we would all be unemployed From Firewalls-Owner@GreatCircle.COM Fri Jan 7 17:41:34 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06006; Fri, 7 Jan 94 17:41:34 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05999; Fri, 7 Jan 94 09:41:27 PST Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA10023(telemann.inoc.dl.nec.com); Fri, 7 Jan 94 11:42:50 CST Received: by texas.syl.dl.nec.com (4.1/YDL1.9-930614.17) id AA18160(texas.syl.dl.nec.com); Fri, 7 Jan 94 11:42:49 CST Received: by florida.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA28486(florida.syl.dl.nec.com); Fri, 7 Jan 94 11:42:47 CST Date: Fri, 7 Jan 94 11:42:47 CST From: ylee@syl.dl.nec.com (Ying-Da Lee) Message-Id: <9401071742.AA28486@florida.syl.dl.nec.com> To: firewalls@GreatCircle.COM, gscheitl@huber.com Subject: Re: SOCKS - DOS? Windows Cc: ylee@syl.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We are working on it. I am not in any position to promise a definite timeframe, but it is probably not overly optimistic to expect a working set of SOCKSified finger/telnet/ftp for Winsock by the end of March. 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@GreatCircle.COM Fri Jan 7 17:47:00 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06027; Fri, 7 Jan 94 17:47:00 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06019; Fri, 7 Jan 94 09:46:49 PST Received: by relay.tis.com; id AA13822; Fri, 7 Jan 94 12:48:01 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma013816; Fri Jan 7 12:47:03 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA25151; Fri, 7 Jan 94 12:47:00 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA10379; Fri, 7 Jan 94 12:46:59 EST Date: Fri, 7 Jan 94 12:46:59 EST From: mjr@tis.com Message-Id: <9401071746.AA10379@otter.tis.com> To: firewalls@greatcircle.com Subject: SOCKS and Firewalls -- Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Gerard: > Is there any way I can access the SOCKS firewall directly from DOS or > Windows without having to go through the SUN and a UNIX environment? Another approach is to use application level proxies, which spoof a protocol enough that you can (almost always) use the standard client applications without modification. This approach doesn't conflict with using SOCKS -- it's just a different design philosophy. For example, from my PC running Sun's PC-NFS (with no modifications) I do the following: C:\TMP> FTP RELAY Connected to relay.tis.com. 220 relay FTP server (Version 5.60mjr) ready. Name (relay:mjr): anonymous@research.att.com 331-(----GATEWAY CONNECTED TO research.att.com----) 331-(220 inet FTP server (Version 4.271 Fri Apr 9 10:11:04 EDT 1993) ready.) 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> What SOCKS gives you is the automatic re-routing of the call (to use X.25ish terms) so the firewall connects to where you really want to connect. Simple proxies like the FTP proxy I just demonstrated force the user to manually re-route the call. You notice that instead of trying to log into the FTP server on RELAY as a user, I told it: anonymous@research.att.com and it "understood" the address and rerouted the call. A set of proxies for FTP, rlogin, and telnet, are available as part of the TIS firewall toolkit. (FTP from ftp.tis.com, in pub/firewalls/toolkit) mjr. From Firewalls-Owner@GreatCircle.COM Fri Jan 7 18:03:27 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06119; Fri, 7 Jan 94 18:03:27 GMT Received: from p-o.ans.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06112; Fri, 7 Jan 94 10:03:19 PST Received: by p-o.ans.net id AA15088 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Fri, 7 Jan 1994 12:58:41 -0500 Message-Id: <199401071758.AA15088@p-o.ans.net> Date: Fri, 7 Jan 94 12:56:10 EST From: "Andrew T. Robinson" To: reh@cs.UMD.EDU, firewalls@greatcircle.com Subject: Broadcast storm Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk My purpose in posting the "data security" posting was not to discuss the opinions it represented but to get some technical answers regarding some of the issues it raises--i.e., can and do (as I thought) firewalls prevent most of the scenarios described? are sophisticated, "cuckoo's nest" connection laundering attacks indeed typical (they should be defeated by a good firewall, anyway)? Andy From Firewalls-Owner@GreatCircle.COM Fri Jan 7 18:11:50 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06146; Fri, 7 Jan 94 18:11:50 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06139; Fri, 7 Jan 94 10:11:38 PST Received: from West.Sun.COM (west.West.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA14803; Fri, 7 Jan 94 10:12:42 PST Received: from maui.West.Sun.COM by West.Sun.COM (4.1/SMI-4.1) id AA01072; Fri, 7 Jan 94 10:12:50 PST Received: from twiddle.West.Sun.COM by maui.West.Sun.COM (4.1/SMI-4.1) id AA12381; Fri, 7 Jan 94 10:12:48 PST Received: by twiddle.West.Sun.COM (5.0/SMI-SVR4) id AA01578; Fri, 7 Jan 1994 10:12:56 +0800 Date: Fri, 7 Jan 1994 10:12:56 +0800 From: Paul.Danielson@West.Sun.COM (Paul Danielson) Message-Id: <9401071812.AA01578@twiddle.West.Sun.COM> To: Firewalls@GreatCircle.COM Subject: Re: MIME questions X-Sun-Charset: US-ASCII Content-Length: 506 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At least one postscript virus exists. The program would change the password on printer, thus locking out the legitimate operators (most postscript printers never have the password system set up, so the default password is in place). It showed up (to my knowledge) about 1.5 years ago, then disappeared. Paul > In a similar vein, I'm amazed I haven't heard of a postscript virus. > I download lots of files and print them without having a clue if some > global printer parameter isn't being messed with. From Firewalls-Owner@GreatCircle.COM Fri Jan 7 18:43:05 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06246; Fri, 7 Jan 94 18:43:05 GMT Received: from nsco.network.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06239; Fri, 7 Jan 94 10:42:53 PST Received: from nscultrix2.network.com by nsco.network.com (5.61/1.34) id AA16594; Fri, 7 Jan 94 12:46:36 -0600 Received: by nscultrix2.network.com (5.57/Ultrix3.0-C) id AA03453; Fri, 7 Jan 94 12:42:58 CST Date: Fri, 7 Jan 94 12:42:58 CST From: dotytr@nscultrix2.network.com (Ted Doty) Message-Id: <9401071842.AA03453@nscultrix2.network.com> To: Remy.Giraud@meteo.fr, john.lines@aea.orgn.uk Subject: Re: packet logging on NSC routers Cc: dotytr@nscultrix2.network.com, firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk john.lines@aea.orgn.uk writes: >Remy.Giraud@meteo.fr writes : [stuff deleted] >> And all the packet coming through the router either discarded or not >> may be copyied to a logging host. > ___________________________ >> Hope this helps >> Remy >> >We use an NSC router and would like to be able to look at packets which >fail some of our filters. > >Have you implemented a program which picks up packets from the 'copy_to' >filter action, and if so would you be willing to let me have a copy. This has >been on my things to do list for a while, but if it has already been done then >this would save reinventing the wheel. > We have written a BSD daemon to collect these messages, which are displayed in a MOTIF front end. You can optionally log these to disk, view and/or log the offending packets, and generate arbitrary unix commands upon receipt of one of these events. The package is called PS216, "PCF Logger" - Ted -------------------------------------------------------------------------- Ted Doty, Network Systems Corporation | phone: +1 301 596-2270 8965 Guilford Road, Suite 250 | fax: +1 410 381-3320 Columbia, MD, 21046 USA | voice mail: (800) 233-1485 -------------------------------------------------------------------------- These opinions are my own, not necessarially those of Network Systems. From Firewalls-Owner@GreatCircle.COM Sat Jan 8 00:09:23 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06944; Sat, 8 Jan 94 00:09:23 GMT Received: from mailgate.prod.aol.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06933; Fri, 7 Jan 94 16:09:15 PST Received: by mailgate.prod.aol.net (1.37.109.4/16.2) id AA05024; Fri, 7 Jan 94 17:01:20 -0500 From: ptrick@aol.com X-Mailer: America Online Mailer Reply-To: Message-Id: <9401071701.tn41531@aol.com> To: firewalls@GREATCIRCLE.COM Date: Fri, 07 Jan 94 17:01:19 EST Subject: Firewalls Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Please add my name to the mailing list... I am currently studying database security as a concentration of a CS degree. Thanks! Patrick J. Mannion - PTrick@AOL.com From Firewalls-Owner@GreatCircle.COM Sat Jan 8 00:16:18 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07065; Sat, 8 Jan 94 00:16:18 GMT Received: from large.cisco.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07058; Fri, 7 Jan 94 16:16:11 PST Received: from localhost by large.cisco.com with SMTP id AA00437 (5.67a/IDA-1.5 for ); Fri, 7 Jan 1994 11:17:45 -0800 Message-Id: <199401071917.AA00437@large.cisco.com> To: Firewalls@GreatCircle.COM Subject: Re: MIME questions In-Reply-To: Your message of "Fri, 07 Jan 1994 10:12:56 +0800." <9401071812.AA01578@twiddle.West.Sun.COM> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Fri, 07 Jan 1994 11:17:44 -0800 From: David Carrel Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" > At least one postscript virus exists. The program would change the > password on printer, thus locking out the legitimate operators (most > postscript printers never have the password system set up, so the > default password is in place). It showed up (to my knowledge) about 1.5 > years ago, then disappeared. I can even easily delete files on the machine you are reading mail on by using a MIME message. PostScript allows for writing/reading/deleting of files. The following message part will delete a file in your current directory that is named "DELETE_THIS_FILE_PLEASE_DAVE". Try it. Create the file, and then read this message. If you have a file by that name that you want saved, then don't preview the next message part. Of course you can protect yourself from this and I'm sure that many on this list have. If you use ghostscript to preview MIME message parts, then make sure that you invoke it with the "-dSAFER" switch. This will protect you from most file related attacks. There may be others. ---------------------------------------------------------------------------- David Carrel | E-mail: carrel@cisco.com Security Development, Cisco Systems | phone: (415) 324-5207 P.O. Box 3075, 1525 O'Brien Dr. | fax: (415) 903-7111 Menlo Park, Ca, 94025-1435 | These words are mine, not Cisco's ---------------------------------------------------------------------------- ------- =_aaaaaaaaaa0 Content-Type: application/postscript Content-Description: this deletes a file %! (DELETE_THIS_FILE_PLEASE_DAVE) deletefile quit ------- =_aaaaaaaaaa0-- From Firewalls-Owner@GreatCircle.COM Fri Jan 7 16:18:15 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06988; Sat, 8 Jan 94 00:13:41 GMT Received: from hawkwind.utcs.toronto.edu (hawkwind.utcs.utoronto.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06981; Fri, 7 Jan 94 16:13:34 PST Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <24070>; Fri, 7 Jan 1994 16:49:26 -0500 To: firewalls@greatcircle.com Subject: Logging mountd Date: Fri, 7 Jan 1994 16:49:20 -0500 From: Chris Siebenmann Message-Id: <94Jan7.164926est.24070@hawkwind.utcs.toronto.edu> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've been surprised by the level of interest in my mountd patches to log attempted NFS mounts. I've put them up on for ftp ftp.sys.utoronto.ca as /pub/mountd.patches. - cks From Firewalls-Owner@GreatCircle.COM Sat Jan 8 00:22:53 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07172; Sat, 8 Jan 94 00:22:53 GMT Received: from akasha.tic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07165; Fri, 7 Jan 94 16:22:40 PST Received: by akasha.tic.com (5.65/akasha.m4.1.14) id AA16132; Fri, 7 Jan 94 13:55:51 -0600 Message-Id: <9401071955.AA16132@akasha.tic.com> To: "John B. Brown" Cc: jsq@tic.com, firewalls@greatcircle.com, hobbit@ftp.com, kemasa@ghost.hac.com, mjr@tis.com Subject: Re: Opinion requested In-Reply-To: Your message of "Fri, 07 Jan 94 14:05:23 EST." <199401071905.AA12897@terminus.cs.umb.edu> Date: Fri, 07 Jan 94 13:55:44 -0600 From: jsq@tic.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > The illusion that the net consists of anything other >than hosts, wires, transcievers, and whatever other devices are >used for communications, is not helpful to rational discussion of The illusion that human perception consists of anything other than matter, photons, heat, chemical reactions, and whatever other physical interactions are used for communications, is not helpful to rational discussion of.... Speaking of rational discussion, I agree with the idea several have put forward that the firewalls list should get back to it. From Firewalls-Owner@GreatCircle.COM Sat Jan 8 00:36:43 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07295; Sat, 8 Jan 94 00:36:43 GMT Received: from catalyst.math.ufl.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07288; Fri, 7 Jan 94 16:36:35 PST From: bb@math.ufl.edu Received: by catalyst.math.ufl.edu (4.1/4.03) id AA05175; Fri, 7 Jan 94 16:56:35 EST Message-Id: <9401072156.AA05175@catalyst.math.ufl.edu> To: firewalls@GreatCircle.COM Subject: Re: SunOS 4.x chroot(2) In-Reply-To: Your message of Fri, 07 Jan 94 07:39:23 -0500. <9401071238.AA04902@mycroft.GreatCircle.COM> Date: Fri, 07 Jan 94 16:56:35 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk smb@research.att.com writes: > The saving grace is that most programs don't open directories, and > in particular don't open / However the few that do are almost certainly using chroot :-) Another member of the League for Programming Freedom (LPF) lpf@uunet.uu.net ------------------------------------------------------------------------------- Brian Bartholomew - bb@math.ufl.edu - EX-Univ. of Florida Dept. of Mathematics From Firewalls-Owner@GreatCircle.COM Fri Jan 7 16:41:00 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07269; Sat, 8 Jan 94 00:34:11 GMT Received: from mail-relay-2 (mail-relay-2.mv.us.adobe.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07262; Fri, 7 Jan 94 16:33:58 PST Received: by mail-relay-2; id AA13407; Fri, 7 Jan 94 14:22:05 -0800 Received: by guardi.mv.us.adobe.com; id AA16063; Fri, 7 Jan 94 14:22:02 -0800 Message-Id: <9401072222.AA16063@guardi.mv.us.adobe.com> To: firewalls@greatcircle.com Subject: Protocol level security and socks Date: Fri, 07 Jan 1994 14:22:00 -0800 From: Tim Guarnieri Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've been thinking about using socks for mosaic. However, one thing I'm not comfortable with is that, after some initial connection-level "interference", sockd basically "glues" the two file descriptors together effectively making the resulting connection the same as a direct connection between the client(s) on the "inside" network and the server(s) on the Internet. Arguably, the socks connection-level IP address screening can keep "outside" connections from being made to the sockd on the firewall, but that can be accomplished in other ways as well (tcpd). What is bothering me is that, once you have cooperating processes on either end of a TCP connection, unless you do some form of "protocol screening" on the packets that pass through the firewall relay daemon (sockd in this case), Bad Things could potentially be done to the client machine(s) on the inside network via the protocol being used over that connection. To be fair, I don't know much about the protocol(s) mosaic uses, so I don't know how much of a risk would be posed to the client machine in the scenario I've just described. My preference would be to have a protocol-specific relay that only allows certain elements of the protocol through (i.e. "read only") to the client machine(s) unless some form of strong authentication were used in which case "write" would be permitted across the connection from the client host(s) to the server(s). I don't know if such a beast exists for the mosaic protocol(s). Anyway, the questions I have for the members of this list are: (1) Does a protocol-specific relay exist for mosaic? If not, is anyone thinking of writing one or know someone who is? (2) How big of a risk do people feel the current socks approach poses to the client machines on the "inside" network? Is this risk large enough to not offer services such as mosaic via socks? Note: in the absense of a solution to question (1), there doesn't appear to be any alternative to socks. (3) General question: Do people believe that connection-level "interference" is "good enough" and that cooperating processes across a TCP connection without protocol-level screening is "overkill"? For the record, my own view is that (socks or no socks), direct connections between inside hosts and Internet hosts without some "controls" on the protocol(s) used across the connection is risky and should be avoided if at all possible. The reason I am looking at socks for mosaic is that I know of no other alternative. Tim From Firewalls-Owner@GreatCircle.COM Fri Jan 7 19:41:00 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08115; Sat, 8 Jan 94 03:29:16 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08108; Fri, 7 Jan 94 19:28:59 PST Received: by relay.tis.com; id AA18687; Fri, 7 Jan 94 22:29:42 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma018685; Fri Jan 7 22:28:53 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA08437; Fri, 7 Jan 94 22:28:50 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA12311; Fri, 7 Jan 94 22:28:49 EST Date: Fri, 7 Jan 94 22:28:49 EST From: mjr@tis.com Message-Id: <9401080328.AA12311@otter.tis.com> To: firewalls@GreatCircle.COM, timg@mv.us.adobe.com Subject: Re: Protocol level security and socks Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >The reason I am looking >at socks for mosaic is that I know of no other alternative. One of our folks here has put together a simple trigger program that allows you to start programs running in a chrooted directory on our firewall bastion host. One of those programs is a copy of mosaic -- especially untrusted since we can't build it from source. As if the source is easily reviewable in the first place. When you run the invoker on your workstation, it invokes the application on the firewall, with its $DISPLAY set back to your workstation. Pros: It's easy and clearly understandable and you don't have to build and screen applications. Cons: you can't write to the local directory or do any disk writes at all other than to a temporary directory. Definitely, supporting gopher and WAIS and whatnot through firewalls is a "hot topic." Lots of folks I've talked to lately: "well -- we want to be able to have complete access to everything on the net, with absolute security." :) It's unfortunate that a lot of the new, sexy protocols have sprung up with only a rudimentary security model and very little in the way of hooks to hang authentication on. I predict that we'll continue to see more and more problems in this regard, as the internet becomes the "hot place" and more and more people with no awareness of security start developing protocols and applications. I don't know what we firewallers can do, since our role is often seen as an obstruction to doing c00l stuff. With respect to Tim's observations about plug-board proxies like SOCKS and plug-gw, I'm in complete agreement (and more or less just as stumped for a solution). I don't see how using plug-board applications is much better than just using router access lists -- conceptually, they are the same thing other than the audit trail, which is perforce minimal since it's at a connection level. The other day a bunch of us were kicking around the "what's the *right* way to do a firewall" (this is a risk when you work in a building full of computer security folks) and truly, the most elegant solutions would rely on infrastructure things that simply aren't there in the conventional IP/UNIX environment. For example, it is nearly trivial to implement a very very strong and quite flexible firewall if you assume the availability of a true multilevel security O/S on your box. The firewall takes all data coming in from the outside and labels it as "internet stuff" and you simply enforce a few restrictions on what processing can be done by anything that's labelled as having touched "internet stuff." On the flip side, you have the firewall permit any outgoing connections for anything labelled "internet stuff" (Here I am assuming the firewall is working at a protocol level, looking at labels on cryptographically signed packets, not at an application level). So if I want to run an X session to the outside, I just make sure I log in at an "internet stuff" level and I have a wide open connection. Anything I do is only capable of accessing unimportant data at that level. Once I pull all my FTPs in and have all my new data lying around in /tmp, if I want to explicitly import it into my "real" system, I'd have to run a trusted guard program that relabels the former "internet stuff" into some kind of unsensitive label for internal use. The guard might do something like throw out MIME and X.400 mail.. :) If I wanted to export data, I'd run a similar process in reverse, and if I wanted to send mail, I'd use a mailer that created "internet stuff" labelled files. Done right, such a system would be nearly transparent, and would have pretty darn good security. Outside of a DOD community, I very much doubt that we'll see that kind of stuff, though. mjr. From Firewalls-Owner@GreatCircle.COM Sat Jan 8 05:30:15 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08297; Sat, 8 Jan 94 05:30:15 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08283; Fri, 7 Jan 94 21:30:05 PST Received: by terminus.cs.umb.edu id AA12897 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Fri, 7 Jan 1994 14:05:23 -0500 Date: Fri, 7 Jan 1994 14:05:23 -0500 From: "John B. Brown" Message-Id: <199401071905.AA12897@terminus.cs.umb.edu> To: jbb@cs.umb.edu, jsq@tic.com Subject: Re: Opinion requested Cc: firewalls@greatcircle.com, hobbit@ftp.com, kemasa@ghost.hac.com, mjr@tis.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From jsq@tic.com Thu Jan 6 03:21:17 1994 > > I don't live in my computer. Neither does anyone else. > Do you live in your office? Your car? No? > Are you only alive then, when you are in your house? > Or do you just stop living when you use your computer? I think, it may be you've got the movie "'TRON' in mind? > The problem I see with the analogy of an Internet node as a house > is that it is too limiting. The Internet is not a small suburb. > It is a diverse subset of the entire world, with homes, businesses, > government offices, NGOs, academic institutions, etc. Trivializing > it as virtual or a place where nobody lives misses the point. Which point is that? The world of 'Neuromancer'? The criminalization of curiosity by electron? > I would log an NFS mount attempt, but I wouldn't contact CERT. > For that matter, we log all anonymous FTP transfers; > the resulting data makes nice maps. The illusion that the net consists of anything other than hosts, wires, transcievers, and whatever other devices are used for communications, is not helpful to rational discussion of network security problems. Inviting another layer of bureaucracy into the problem, one that defines social problems and crimes, wont help find answers to the technical problems of computer data security. There are limited resources available for information interchange. I think any resource spent over and above CPU time on computer security is a waste. Having said that, I beleive effort expended in making protection automatic is well spent; chasing 'criminals' is a waste. Remember Parkinson's Law! Shalom, JBB. From Firewalls-Owner@GreatCircle.COM Sat Jan 8 14:48:34 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09493; Sat, 8 Jan 94 14:48:34 GMT Received: from srv.cip.physik.tu-muenchen.de ([129.187.184.1]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09485; Sat, 8 Jan 94 06:48:23 PST Received: from nugget.cip.physik.tu-muenchen.de by srv.cip.physik.tu-muenchen.de with SMTP id AA00949 for (5.67a/IDA-1.5/bs03); Sat, 8 Jan 1994 15:49:30 +0100 Message-Id: <199401081449.AA00949@srv.cip.physik.tu-muenchen.de> To: Tim Guarnieri Cc: firewalls@greatcircle.com Subject: Re: Protocol level security and socks In-Reply-To: Your message of "Fri, 07 Jan 94 14:22:00 PST." <9401072222.AA16063@guardi.mv.us.adobe.com> Date: Sat, 08 Jan 94 15:49:30 +0100 From: Bernhard.Schneck@Physik.TU-Muenchen.DE Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9401072222.AA16063@guardi.mv.us.adobe.com> you write: > I've been thinking about using socks for mosaic. [...] >From the Mosaic for X, Version 2.1 "`What's new"' Document: * Merged in SOCKS modifications from Ying-Da Lee (ylee@syl.dl.nec.com); * for the version of SOCKS needed to compile with SOCKS support enabled, * see here; note that SOCKS and the SOCKS code now in Mosaic are NOT * supported by NCSA. > Anyway, the questions I have for the members of this list are: > > (1) Does a protocol-specific relay exist for mosaic? If not, is > anyone thinking of writing one or know someone who is? There are several HTTP daemons, some of which can (at least) do request forwarding (Plexus can do it, and as far as I know the NCSA httpd can do it, too). There is an pre-alpha version of `request caching' for Plexus (so if 2 people want to look at the same document, it only gets fetched once over the Net). The X11 version of Mosaic allows using such a HTTP forwarder through the environment variables WWW_http_GATEWAY and WWW_gopher_GATEWAY. You can run such a daemon on your firewall (or on a specially designated host within your firewall net with access to the InterNet), point all your WWW clients to it, and it should work. An other question is about the security of the data transported through the HTTProtocol (eg. the PostScript delete-file attack). BTW, HTTP1.0 has (at least some) security functions for authentication built into the protocol. I don't know how widely these are supported already. \Bernhard. From Firewalls-Owner@GreatCircle.COM Sat Jan 8 17:11:02 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10549; Sun, 9 Jan 94 00:56:38 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10541; Sat, 8 Jan 94 16:56:25 PST Message-Id: <9401090056.AA10541@mycroft.GreatCircle.COM> To: jbb@cs.umb.edu, jsq@tic.com, firewalls@greatcircle.com, hobbit@ftp.com, kemasa@ghost.hac.com, mjr@tis.com Subject: Re: Opinion requested In-Reply-To: Your message of Fri, 7 Jan 1994 14:05:23 -0500 Date: Sat, 08 Jan 1994 16:56:22 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk OK, I think we've all had our fill of opinions for the new year; let's just stop here, and not continue this any further. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Mon Jan 10 12:08:33 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA16158; Mon, 10 Jan 94 12:08:33 GMT Received: from eandm.co.il (bones.eandm.co.il) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA16151; Mon, 10 Jan 94 04:08:20 PST Received: from fozzy.eandm.com (fozzy.eandm.co.il) by eandm.co.il (4.1/SMI-4.0) id AA00481; Mon, 10 Jan 94 14:07:43 IST Date: Mon, 10 Jan 94 14:07:43 IST From: Gil Shwed - Software Message-Id: <9401101207.AA00481@eandm.co.il> To: firewalls@greatcircle.com Subject: Firewall Cost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk What is the cost of implementing firewall solutions like DEC SEAL, Raptor Eagle, TAMU or any other? Email to me and I'll summarize. -- Thanks In Advance, -- Gil Shwed gil@eandm.co.il From Firewalls-Owner@GreatCircle.COM Mon Jan 10 16:30:07 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA16750; Mon, 10 Jan 94 16:30:07 GMT Received: from lns62.lns.cornell.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA16736; Mon, 10 Jan 94 08:29:52 PST Received: from LNS62.LNS.CORNELL.EDU by LNS62.LNS.CORNELL.EDU (PMDF V4.2-13 #3448) id <01H7IL7YIVMO8WYCAA@LNS62.LNS.CORNELL.EDU>; Mon, 10 Jan 1994 11:33:15 EST Date: Mon, 10 Jan 1994 11:33:15 -0500 (EST) From: "Selden E. Ball, Jr." Subject: Re: MIME questions To: carrel@cisco.com, Firewalls@GreatCircle.COM Message-Id: <01H7IL7YKHHU8WYCAA@LNS62.LNS.CORNELL.EDU> X-Vms-To: IN%"carrel@cisco.com",IN%"Firewalls@GreatCircle.COM" X-Vms-Cc: SEB Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A minor quibble with David Carrel's recently posted message: he wrote >I can even easily delete files on the machine you are reading mail on by >using a MIME message. PostScript allows for writing/reading/deleting of >files. The actual execution of a PostScript interpreter is not part of the requirements of the MIME RFC. In fact, section 7.4.2 of RFC1341 lists several reasons why this is a bad idea, and strongly urges that any interpreter that is used should disable various damaging commands. Other MIME "application" agents can have comparable problems. "Obviously" system administrators who are concerned about security should be familiar with the standard and with the MIME agents being used on their systems. Selden ------ Selden E. Ball, Jr. Cornell University Voice: +1-607-255-0688 Laboratory of Nuclear Studies FAX: +1-607-255-8062 230A Wilson Synchrotron Lab BITNET: SEB@CRNLNS Judd Falls & Dryden Road Internet: SEB@LNS61.TN.CORNELL.EDU Ithaca, NY, USA 14853-8001 HEPnet/SPAN: LNS61::SEB = 44283::SEB From Firewalls-Owner@GreatCircle.COM Mon Jan 10 17:48:42 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA17826; Mon, 10 Jan 94 17:48:42 GMT Received: from iphase.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA17819; Mon, 10 Jan 94 09:48:30 PST Received: from chip.iphase.com by iphase.com (4.1/1.34) id AA12539; Mon, 10 Jan 94 11:50:02 CST Received: by chip.iphase.com (4.1/SMI-4.1-Goofy) id AA15104; Mon, 10 Jan 94 11:50:00 CST From: plarkin@iphase.com (Patrick Larkin Jr) Message-Id: <9401101750.AA15104@chip.iphase.com> Subject: Critique my Firewall To: firewalls@greatcircle.com Date: Mon, 10 Jan 1994 11:49:59 -0600 (CST) Reply-To: plarkin@iphase.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5050 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Here's a representation of what I am planning for our firewall. Please point out any deficiencies and look at my questions at the end. All ports < 1024 are blocked except ftp/telnet/etc ------------ to bastion only ----------- No user Accts. <--to internet | Cisco IGS |--->----->------>| bastion | inbound telnet ++++++++++++++++++++| router |=================| host | authentication, all outgoing <---| | & nntp into | | DNS, smtp frwd pkts allowed ------------ server inside ----------- and ftp servr from MIS approved || internal hosts || || ----------- ------------ modem-----| |<--<-->-->| | User accts for modem-----| Netblazer |==========| UUCP host | those needing modem-----| |->->||<-<-| | uucp stuff ----------- || ------------ user accts || | | for dial-ins || | | & SLIP/PPP || modem modem "DMZ" Subnet || ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~||~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Internal Net || -------- | router | Is this router REQUIRED? | ??? | Should it be placed between -------- Bastion and rest of internal || Net (moving DMZ outside || Modems)? ---------- || | NNTP | ------------ | Server |=========| | ---------- | Cisco AGS |=========Internal Subnet Internal Subnet========| (no filter)| ------------ || || || || || || Internal Subnets ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Key: ++++++++ 56 kbs -->-->--> Logical Path of TCP/IP Packets All traffic is free to pass --------- Serial Line(s) except for filters on External Cisco router. Filters there ======= Deny all inbound packets < 1024 || Ethernet Except ports for smtp, ftp, nntp || & telnet ONLY if destined for Bastion host. All hosts (including bastion) will "dumbly" forward mail to an SMTP server (probably the same one as the NNTP Server. My questions are primarily centered on the middle router named "???". We do not really plan to implement this router because it seems redundant. All the filtering is done on the 'IGS' and it only forwards approved packets to the bastion (except NNTP is only forwarded to NNTP server). We do not want any filters on the AGS for performance reasons. What would router "???" buy us other than backup in case the IGS threw-up and started allowing unfiltered packets? (What are the chances of that happening anyway?) Also, would there be any benefit to moving the UUCP host and Netblazer host to a subnet other than the DMZ? The ultimate goal will be to provide unlimitted access TO the Internet FROM selected hosts within our net and to allow nothing but SMTP, NNTP, FTP, NTP, and TELNET FROM the Internet TO the Bastion host (and NNTP Server for NNTP). The idea with Telnet to Bastion is that we would implement Challenge Tokens to access the "Gatekeeper" account there and then telnet to the user's choice of selected internal hosts. We would prefer NOT implementing SOCKS due to the requirements for client modifications. Any comments you have would be helpful. P.S. Thanks to those who commented on my questions about accessing then Internet from Unsecured internal hosts. -- +=======================================================================+ | PATRICK H LARKIN, JR. - System Administrator, Interphase Corp, Dallas | |>---------------------------------------------------------------------<| | "Remember 'Rock Climbing'? Now we have 'Hypno-Helio-Static-Stasis'!" | | -- Dr. Clayton Forrester, Deep 13 - MST 3000 | \_____________________________________________________________________/ From Firewalls-Owner@GreatCircle.COM Mon Jan 10 19:21:22 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18249; Mon, 10 Jan 94 19:21:22 GMT Received: from lns62.lns.cornell.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18236; Mon, 10 Jan 94 11:21:12 PST Received: from LNS62.LNS.CORNELL.EDU by LNS62.LNS.CORNELL.EDU (PMDF V4.2-13 #3448) id <01H7IR5I6WXS8WYCAA@LNS62.LNS.CORNELL.EDU>; Mon, 10 Jan 1994 14:24:31 EST Date: Mon, 10 Jan 1994 14:24:31 -0500 (EST) From: "Selden E. Ball, Jr." Subject: Re: MIME questions To: Firewalls@GreatCircle.COM Message-Id: <01H7IR5I6WXU8WYCAA@LNS62.LNS.CORNELL.EDU> X-Vms-To: IN%"Firewalls@GreatCircle.COM" X-Vms-Cc: SEB Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Does anyone know of a "Secure PostScript Interpreter" as described in the MIME RFC (1341) in section 7.4.2? Thanks, Selden ------ Selden E. Ball, Jr. Cornell University Voice: +1-607-255-0688 Laboratory of Nuclear Studies FAX: +1-607-255-8062 230A Wilson Synchrotron Lab BITNET: SEB@CRNLNS Judd Falls & Dryden Road Internet: SEB@LNS61.TN.CORNELL.EDU Ithaca, NY, USA 14853-8001 HEPnet/SPAN: LNS61::SEB = 44283::SEB From Firewalls-Owner@GreatCircle.COM Mon Jan 10 19:25:03 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18303; Mon, 10 Jan 94 19:25:03 GMT Received: from checkpoint.brm.co.il (pc150.brm.co.il) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18279; Mon, 10 Jan 94 11:24:31 PST Received: from monk.UUCP by checkpoint.brm.co.il (4.1/SMI-4.0) id AA01473; Mon, 10 Jan 94 21:28:15 IST Received: by checkpoint.brm.co.il (4.1/SMI-4.1) id AA13529; Mon, 10 Jan 94 21:23:44 IST Date: Mon, 10 Jan 94 21:23:44 IST From: gil@checkpoint.brm.co.il (Gil Shwed) Message-Id: <9401101923.AA13529@checkpoint.brm.co.il> To: firewalls@GreatCircle.COM, plarkin@iphase.com Subject: Re: Critique my Firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Patrick, This configuration looks pretty intersting ... How do you intend to protect your network from the SLIP/UUCP hosts? Maybe it might be better to put the Netblazer and/or the UUCP host in front of the IGS router? How do you intend to allow outgoing services like FTp or archie from the "selected hosts" (ftp-data connections and replies to UDP requests)? And maybe the most important question: How do you intend to manage this configuration, and to assure it's operation? > From: plarkin@iphase.com (Patrick Larkin Jr) > > Here's a representation of what I am planning for our firewall. > Please point out any deficiencies and look at my questions at the end. > > > > All ports < 1024 > are blocked except > ftp/telnet/etc > ------------ to bastion only ----------- No user Accts. > <--to internet | Cisco IGS |--->----->------>| bastion | inbound telnet > ++++++++++++++++++++| router |=================| host | authentication, > all outgoing <---| | & nntp into | | DNS, smtp frwd > pkts allowed ------------ server inside ----------- and ftp servr > from MIS approved || > internal hosts || > || > ----------- ------------ > modem-----| |<--<-->-->| | User accts for > modem-----| Netblazer |==========| UUCP host | those needing > modem-----| |->->||<-<-| | uucp stuff > ----------- || ------------ > user accts || | | > for dial-ins || | | > & SLIP/PPP || modem modem > "DMZ" Subnet || > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~||~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Internal Net || > -------- > | router | Is this router REQUIRED? > | ??? | Should it be placed between > -------- Bastion and rest of internal > || Net (moving DMZ outside > || Modems)? > ---------- || > | NNTP | ------------ > | Server |=========| | > ---------- | Cisco AGS |=========Internal Subnet > Internal Subnet========| (no filter)| > ------------ > || || > || || > || || > Internal Subnets > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Key: > ++++++++ 56 kbs > > -->-->--> Logical Path of TCP/IP Packets > All traffic is free to pass > --------- Serial Line(s) except for filters on External > Cisco router. Filters there > ======= Deny all inbound packets < 1024 > || Ethernet Except ports for smtp, ftp, nntp > || & telnet ONLY if destined for > Bastion host. > -- Gil Shwed -- CheckPoint Software Technologies -- gil@checkpoint.brm.co.il From Firewalls-Owner@GreatCircle.COM Mon Jan 10 19:53:44 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18408; Mon, 10 Jan 94 19:53:44 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18401; Mon, 10 Jan 94 11:53:36 PST Received: by relay.tis.com; id AA06178; Mon, 10 Jan 94 14:54:55 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma006168; Mon Jan 10 14:53:59 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA08656; Mon, 10 Jan 94 14:53:52 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA20900; Mon, 10 Jan 94 14:53:51 EST Date: Mon, 10 Jan 94 14:53:51 EST From: mjr@tis.com Message-Id: <9401101953.AA20900@otter.tis.com> To: Firewalls@GreatCircle.COM, SEB@LNS62.LNS.CORNELL.EDU Subject: Re: MIME questions Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Does anyone know of a "Secure PostScript Interpreter" as described >in the MIME RFC (1341) in section 7.4.2? /bin/rm mjr. From Firewalls-Owner@GreatCircle.COM Mon Jan 10 20:28:38 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18629; Mon, 10 Jan 94 20:28:38 GMT Received: from london.micrognosis.com (midas.london.micrognosis.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18617; Mon, 10 Jan 94 12:28:21 PST Received: by london.micrognosis.com (4.1/NAR-Gateway) id AA09562; Mon, 10 Jan 94 20:29:27 GMT Received: from zeus.london.micrognosis.com(192.83.165.17) by midas via smap (V1.0mjr) id sma009560; Mon Jan 10 20:29:23 1994 Received: from moria by zeus.london.micrognosis.com (4.1/SMI-4.1) id AA12987; Mon, 10 Jan 94 20:29:20 GMT From: nreadwin@london.micrognosis.com (Neil Readwin) Received: by moria (4.1//ident-1.0) id AA14919; Mon, 10 Jan 94 20:29:19 GMT Message-Id: <9401102029.AA14919@moria> Subject: Re: Critique my Firewall To: plarkin@iphase.com Date: Mon, 10 Jan 1994 20:29:19 +0000 (GMT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9401101750.AA15104@chip.iphase.com> from "Patrick Larkin Jr" at Jan 10, 94 11:49:59 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1737 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Patrick Larkin Jr writes: > Here's a representation of what I am planning for our firewall. > Please point out any deficiencies and look at my questions at the end. Do you really mean to have an Ethernet just linking the bastion host and the UUCP host or did you mean something like: +++ IGS ======= Bastion ====== Router? ======= AGS ======= Internal nets || ==== UUCP host || ==== NetBlazer or even +++ IGS ======= Bastion || ==== UUCP host || ==== NetBlazer || Router? ======= AGS ======= Internal nets If it is the latter then I would be happier with 'Router?' present since dialup PPP onto the trusted network would make me nervous. > All hosts (including bastion) will "dumbly" forward mail to an SMTP > server If all inbound mail is just to user@foo.com and you have an internal DNS that contains different MXs (for foo.com) to the external DNS then the sendmail.cf (or equivalent) on the bastion can be delightfully simple - you just dump *everything* to the same [TCP] mailer channel. > The ultimate goal will be to provide unlimitted access TO the Internet > FROM selected hosts within our net and to allow nothing but SMTP, NNTP, > FTP, NTP, and TELNET FROM the Internet TO the Bastion host (and NNTP > Server for NNTP). What do you really mean by unlimited? If you want users to be able to run arbitrary protocols out to external hosts then you are in effect allowing them to make decisions about whether a particular protocol is safe. They may well not be qualified to make that decision. Neil. -- Phone: +44 71 815 5283 E-mail: nreadwin@micrognosis.co.uk Anything is a cause for sorrow that my mind or body has made From Firewalls-Owner@GreatCircle.COM Tue Jan 11 00:08:22 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19399; Tue, 11 Jan 94 00:08:22 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19392; Mon, 10 Jan 94 16:08:11 PST Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA17540(telemann.inoc.dl.nec.com); Mon, 10 Jan 94 18:09:44 CST Received: by texas.syl.dl.nec.com (4.1/YDL1.9-930614.17) id AA20737(texas.syl.dl.nec.com); Mon, 10 Jan 94 18:09:43 CST Received: by florida.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA01671(florida.syl.dl.nec.com); Mon, 10 Jan 94 18:09:42 CST Date: Mon, 10 Jan 94 18:09:42 CST From: ylee@syl.dl.nec.com (Ying-Da Lee) Message-Id: <9401110009.AA01671@florida.syl.dl.nec.com> To: firewalls@GreatCircle.COM Subject: Re: Protocol level security and socks Cc: ylee@syl.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This was posted to the SOCKS mailing list about a month ago in response to someone's query. Looks like it may be approriate here too. --------------------------------------------------- >I will be working with SOCKS now. Any information would be >appreciated. I just want to know how secure SOCKS is, and what >guarantees can be made about it... Thanks. I don't know about guarantees. Should we start with 'as far as I know, there is no way...' and see where it ends? As far as I know, there is no way to initiate an attack into your firewalled internal network through SOCKS if your SOCKS server is properly configured. For example, if your internal network is 200.100.50 and you put the line deny 0.0.0.0 0.0.0.0 200.100.50.0 255.255.255.0 at the top of your sockd.conf, the SOCKS server will fend off all attempts to go through it to reach your inside hosts. No routing tricks or IP address spoofing will make any difference. This is not to say that you are not incurring some risks by running SOCKS. You are, but these are the risks/vulnerabilities accompanying the applications you allow to run on top of SOCKS, not with SOCKS itself. For example, doing any network communication without encryption runs the risk of having your password or other confidential information stolen, whether you use SOCKS or not. Blindly "displaying" a postscript file can end in a disaster regardless of whether you retrieved the file through SOCKS or not. SOCKS doesn't add more on top of these risks, but it doesn't help you deal with them either. Should it? It really can't if SOCKS is to remain a general purpose TCP relayer without delving into the specific application protocols. This accounts for the server's high effficiency. This independence of the application protocol also makes it easy to convert an application program into a SOCKS client. In addition, SOCKS probably will have a fairly easy time accommodating security devices in the application protocols if and when they are used. So, if on balance you find the security risks of existing telnet, ftp, Mosaic, etc. outweigh their usefulness to you and you are unable or unwilling to develop a more secure version, then SOCKS is not for you. If the balance tilts the other way, welcome to SOCKS. I hope that's enough for a start. 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 ************** The rest of this message was automatically appended by the socks list mail munger. To send a message to the entire list, address it to: socks@inoc.dl.nec.com. However, if you want to get off the list or change your address, please send a message to socks-request@inoc.dl.nec.com, and NOT the entire list. Thank you. ************** From Firewalls-Owner@GreatCircle.COM Tue Jan 11 00:35:56 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19603; Tue, 11 Jan 94 00:35:56 GMT Received: from inesc.inesc.pt by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19596; Mon, 10 Jan 94 16:35:46 PST Received: from inesc.inesc.pt by inesc.inesc.pt with SMTP; id AA06881 (5.67a/SunOS4.1.3); Tue, 11 Jan 1994 01:36:03 +0100 Received: by avila.inesc.pt (4.1/SunOS4.1.2) id AA15362; Tue, 11 Jan 94 01:36:07 +0100 From: prc@avila.inesc.pt (Pedro Ramalho Carlos) Message-Id: <9401110036.AA15362@avila.inesc.pt> Subject: Re: MIME questions To: mjr@tis.com Date: Tue, 11 Jan 1994 01:36:06 +0100 (MET) Cc: Firewalls@GreatCircle.COM, SEB@LNS62.LNS.CORNELL.EDU In-Reply-To: <9401101953.AA20900@otter.tis.com> from "mjr@tis.com" at Jan 10, 94 02:53:51 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 722 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi all > > >Does anyone know of a "Secure PostScript Interpreter" as described > >in the MIME RFC (1341) in section 7.4.2? > > /bin/rm > Wouldn't it be possible to wrap your favourite ps viewer in a "system call intercepter" that would basically redirect all open calls that are not directed to some configurable set of "device files" to /dev/null? i'm not familiar with either PS nor with typical ps viewers legitimate file needs but at a first glance that might seem feasible? Any comments? cheers --- pedro ramalho carlos email: prc@inesc.pt INESC tel: +351-1-3100050 Av. Duque de Avila, 23 fax: +351-1-3100008 1017 Lisboa Codex - PORTUGAL ** Of course there's no reason for it, it's just our policy. ** From Firewalls-Owner@GreatCircle.COM Mon Jan 10 19:11:09 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20050; Tue, 11 Jan 94 02:52:17 GMT Received: from toontown.sw-eng.dts.harris.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07716; Fri, 7 Jan 94 17:33:59 PST Received: by toontown.sw-eng.dts.harris.com (5.0/SMI-SVR4) id AA14146; Fri, 7 Jan 94 17:35:24 PST Date: Fri, 7 Jan 94 17:35:24 PST From: Marcos Della Message-Id: <9401071735.ZM14144@toontown> X-Mailer: Z-Mail (2.1.5 09aug93) To: firewalls@greatcircle.com Subject: How to contact CERT... Content-Length: 362 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Does CERT have a mailing list and if so, how to subscribe? Also how can I get past postings of problem areas? --marcos -- ,,, (o o) -----------------oOO--(_)--OOo------------- Marcos R. Della Harris - Digital Telephone Systems Division Email: marcos.della@dts.harris.com Phone 415/382-5361 FAX 415/382-5395 From Firewalls-Owner@GreatCircle.COM Tue Jan 11 09:09:12 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20983; Tue, 11 Jan 94 09:09:12 GMT Received: from sequent.kiae.su by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20976; Tue, 11 Jan 94 01:08:40 PST Received: from piggy.relcom.msk.su by sequent.kiae.su with SMTP id AA15164 (5.65.kiae-1 for ); Tue, 11 Jan 1994 11:47:53 +0300 Received: from localhost by piggy.relcom.msk.su id LAA00681; (8.3/vak/1.8) Tue, 11 Jan 1994 11:36:08 +0300 Date: Tue, 11 Jan 94 11:36:07 +0300 From: blaster@piggy.relcom.msk.su (Victor A. Borisov) To: firewalls@GreatCircle.COM Message-Id: Organization: Relcom Corp. (Research & Development) Subject: How I can ftp kerberos from Russia? X-Mailer: BML [UNIX Beauty Mail v.1.39] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk !Buenos! Amigas! I want to ftp kerberos, but I live in Russia. Can I ftp one from non american server? Please, give me adress of that server. --- Victor A. Borisov aka blaster; Computer Security Center of Relcom. Email: blaster@rd.relcom.msk.su; Phone: +7(095)-943-4735; Fax: +7(095)-198-9510; === Don`t panic! === From Firewalls-Owner@GreatCircle.COM Tue Jan 11 11:03:15 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA21446; Tue, 11 Jan 94 11:03:15 GMT Received: from srv.cip.physik.tu-muenchen.de ([129.187.184.1]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA21439; Tue, 11 Jan 94 03:02:47 PST Received: from comserv.cip.physik.tu-muenchen.de by srv.cip.physik.tu-muenchen.de with SMTP id AA03098 for (5.67a/IDA-1.5/bs03); Tue, 11 Jan 1994 11:58:00 +0100 Message-Id: <199401111058.AA03098@srv.cip.physik.tu-muenchen.de> To: blaster@piggy.relcom.msk.su (Victor A. Borisov) Cc: firewalls@greatcircle.com Subject: Re: How I can ftp kerberos from Russia? In-Reply-To: Your message of "Tue, 11 Jan 94 11:36:07 +0300." Date: Tue, 11 Jan 94 11:57:59 +0100 From: Bernhard.Schneck@Physik.TU-Muenchen.DE Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message you write: > !Buenos! Amigas! > > I want to ftp kerberos, but I live in Russia. Can I ftp one from > non american server? Please, give me adress of that server. The only version which you can ftp legally from the US is `Bones', Kerberos4 with all references and calls to the DES library stripped. There is an other version called `eBones', that is Bones with encryption put back in. You may (as far as I know) ftp this from anywhere, as long as no single bit of it got ever into US territory (otherwise, you're not allowed to re-export it, even if it originated outside the US). So you better make sure your FTP route does not touch the US anywhere. (an interesting question which I never got completely answered: What if the packets are relayed through an US-owned or US-launched sattelite?) No version of Kerberos5 is yet exportable, though I heard of several sites outside the US who have it. It is illegal (from the US point of view) for you to get it from such a site (it seems they view it as a transitive relation). DCE includes Kerberos5, including all DES encryption calls in all the right places, but with the DES library replaced by a fake routine (desneuter) in international shipped versions (it just does bcopy()) Someone mentioned that export of DES code (or anything else considered munitions by the US government) from any country which has signed the COCOM treaty should be governed by the US laws ... (I'm not sure if this is really true, can't imagine any sovereign country would accept such a clause! But COCOM does help a lot in trade with the US, so maybe it's true anyway) The other question is, what they can do to you ... \Bernhard. PS: this is my personal opinion, based on information mostly obtained from the net. If you want a professional opinion, ask a professional lawyer. PPS: But who can make sense of output from professional lawyers ??? :-) From Firewalls-Owner@GreatCircle.COM Tue Jan 11 13:15:05 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA21869; Tue, 11 Jan 94 13:15:05 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA21860; Tue, 11 Jan 94 05:14:53 PST Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA23286 for ; Tue, 11 Jan 94 08:05:24 -0500 Received: from lorax.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA23012; Tue, 11 Jan 94 08:02:53 EST Received: from localhost by lorax.imsi.com (4.1/SMI-4.1) id AA19828; Tue, 11 Jan 94 08:02:52 EST Message-Id: <9401111302.AA19828@lorax.imsi.com> To: prc@avila.inesc.pt (Pedro Ramalho Carlos) Cc: mjr@tis.com, Firewalls@greatcircle.com, SEB@lns62.lns.cornell.edu Subject: Re: MIME questions In-Reply-To: Your message of "Tue, 11 Jan 1994 01:36:06 +0100." <9401110036.AA15362@avila.inesc.pt> Reply-To: rens@imsi.com Date: Tue, 11 Jan 1994 08:02:52 -0500 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Tue, 11 Jan 1994 01:36:06 +0100 (MET), prc@avila.inesc.pt (Pedro Ramalho Carlos) said: prc> Wouldn't it be possible to wrap your favourite ps viewer in a prc> "system call intercepter" that would basically redirect all prc> open calls that are not directed to some configurable set of prc> "device files" to /dev/null? Not a bad idea. On my system, ghostview opens: open ("/usr/lib/ld.so", 0, 0404120) = 3 open ("/dev/zero", 0, 07) = 4 open ("/etc/ld.so.cache", 0, 05000100021) = 3 open ("/usr/X11R5/lib", 0, 01010525) = 3 open ("/usr/X11R5/lib/libXaw.so.5.0", 0, 0364034) = 3 open ("/usr/X11R5/lib/libXmu.so.4.10", 0, 0364054) = 3 open ("/usr/X11R5/lib/libXt.so.4.10", 0, 0364074) = 3 open ("/usr/X11R5/lib/libXext.so.4.10", 0, 0364114) = 3 open ("/usr/X11R5/lib/libX11.so.4.10", 0, 0364134) = 3 open ("", 0, 037500124000) = 3 open ("/usr/openwin/lib", 0, 0) = 3 open ("/u/pkg/mh/v6.8/lib", 0, 020) = 3 open ("/u/pkg/X11R5/lib", 0, 022) = 3 open ("/usr/lib/libc.so.1.8", 0, 0364234) = 3 open ("/usr/lib/libdl.so.1.0", 0, 0364254) = 3 open ("/var/yp/binding/imsi.com.2", 0, 035733226136) = 3 open ("/u/rens/.Xauthority", 0, 0666) = 6 open ("/u/pkg/X11R5/lib/X11/nls/nls.dir", 0, 0666) = 6 open ("/u/pkg/X11R5/lib/X11/nls/nls.ali".., 0, 0666) = 6 open ("/u/pkg/X11R5/lib/X11/nls/C", 0, 0666) = 6 open ("/u/rens/.Xdefaults-lorax", 0, 0) = -1 ENOENT (No such file or directory) open ("/u/pkg/X11R5/lib/X11/app-default".., 0, 01724) = 6 open ("nwippapr.ps", 0, 0666) = 6 open ("/usr/share/lib/zoneinfo/localtim".., 0, 0) = 7 open ("nwippapr.ps", 0, 0) = 7 Most of this has to do with shared libraries. You could allow any opens where the access is O_RDONLY, and only have an access list for writable opens. This, of course, leaves you open to theft of data, but stops delete/modify attacks; You judge if it's enough. The code to do this is fairly trivial. If there's interest, I'll post a version using sun's ptrace(2) interface. The performance hit can be pretty big, though. -Rens From Firewalls-Owner@GreatCircle.COM Tue Jan 11 08:18:33 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22123; Tue, 11 Jan 94 15:48:16 GMT Received: from mail.netcom.com (netcom3.netcom.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22116; Tue, 11 Jan 94 07:48:09 PST Received: from localhost by mail.netcom.com (8.6.4/SMI-4.1/Netcom) id HAA03730; Tue, 11 Jan 1994 07:50:22 -0800 Date: Tue, 11 Jan 1994 07:50:22 -0800 From: koblas@netcom.com (David Koblas) Message-Id: <199401111550.HAA03730@mail.netcom.com> To: firewalls@greatcircle.com Subject: Re: Protocol level security and socks Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > (1) Does a protocol-specific relay exist for mosaic? If not, is > anyone thinking of writing one or know someone who is? HTTP (the WWW protocol), could be consider receiver secure if you ignore the problems that having MIME style messages. Mosaic will happily receive a PostScript file and popup 'ghostview' for you quite happily, this suffers from all the recent problems people have mentioned about MIME messages. So to do an reasonable job of securing Mosaic you will need to do a LOT of work, not so much in doing protocol "verification" but more message content checks. Maybe there needs to be a more general MIME message security suite, since for every content type you'll want to do a different batch of checks. --koblas@netcom.com ps. How long until people start doing (when their friends send them "cute" little scripts...) application/x-shar; sh %s From Firewalls-Owner@GreatCircle.COM Tue Jan 11 08:41:28 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22262; Tue, 11 Jan 94 16:09:18 GMT Received: from cert.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA21795; Tue, 11 Jan 94 04:45:41 PST Received: from mickey.cert.org by cert.org (4.1/cert-5.2) id AA23346; Tue, 11 Jan 94 07:48:52 EST Received: from localhost.cert.org by mickey.cert.org (4.1/cert-5.3) id AA27360; Tue, 11 Jan 94 07:48:50 EST Message-Id: <9401111248.AA27360@mickey.cert.org> To: Marcos Della Cc: firewalls@greatcircle.com Subject: Re: How to contact CERT... In-Reply-To: Your message of "Fri, 07 Jan 94 17:35:24 PST." <9401071735.ZM14144@toontown> Date: Tue, 11 Jan 94 07:48:50 EST From: georgia@cert.org Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Marcos: > Does CERT have a mailing list and if so, how to subscribe? Also how can > I get past postings of problem areas? Yes, past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from cert.org (192.88.209.5). I have appended our CERT FAQ (Frequently Asked Questions). This should provide you with general information about CERT and the products and services we offer (i.e., how to subscribe to our various mailing lists, etc.). Regards, Georgia Killcrece CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Internet E-mail: cert@cert.org Telephone: 412-268-7090 24-hour hotline: CERT personnel answer 8:30a.m.-5:00p.m. EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours. From Firewalls-Owner@GreatCircle.COM Tue Jan 11 08:48:36 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22500; Tue, 11 Jan 94 16:40:47 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22490; Tue, 11 Jan 94 08:40:38 PST Message-Id: <9401111640.AA22490@mycroft.GreatCircle.COM> To: firewalls@greatcircle.com Subject: Re: Protocol level security and socks In-Reply-To: Your message of Tue, 11 Jan 1994 07:50:22 -0800 Date: Tue, 11 Jan 1994 08:40:37 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk koblas@netcom.com (David Koblas) writes: # # > (1) Does a protocol-specific relay exist for mosaic? If not, is # > anyone thinking of writing one or know someone who is? # # HTTP (the WWW protocol), could be consider receiver secure if you # ignore the problems that having MIME style messages. Mosaic will # happily receive a PostScript file and popup 'ghostview' for you # quite happily, this suffers from all the recent problems people # have mentioned about MIME messages. So to do an reasonable job of # securing Mosaic you will need to do a LOT of work, not so much # in doing protocol "verification" but more message content checks. What about a "-paranoid" option for GhostScript? Have it ask the user for permission before doing any "dangerous" operation. # ps. How long until people start doing (when their friends send # them "cute" little scripts...) # application/x-shar; sh %s This may not be an unreasonable thing to do, IF I know who the message is from (and I'm sure it's from them; i.e., it's authenticated somehow). Depends on how much I trust whoever is sending me the message. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Tue Jan 11 17:43:54 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22706; Tue, 11 Jan 94 17:43:54 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22697; Tue, 11 Jan 94 09:43:26 PST Message-Id: <9401111743.AA22697@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Tue Jan 11 12:40:55 EST 1994 To: Brent Chapman Cc: firewalls@GreatCircle.COM Subject: Re: Protocol level security and socks Date: Tue, 11 Jan 94 12:40:54 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # in doing protocol "verification" but more message content checks. What about a "-paranoid" option for GhostScript? Have it ask the user for permission before doing any "dangerous" operation. Ghostscript has the -dSAFER option; it disables deletefile and renamefile, and will only open files read-only. Ghostview -- the usual way to invoked Ghostscript -- specifies this option by default, according to the man page. # ps. How long until people start doing (when their friends send # them "cute" little scripts...) # application/x-shar; sh %s This may not be an unreasonable thing to do, IF I know who the message is from (and I'm sure it's from them; i.e., it's authenticated somehow). Depends on how much I trust whoever is sending me the message. Ever hear of the IBM Christmas Card virus? Someone wrote the VM/CMS equivalent of a shell script to display an animated Christmas tree, and mailed it to a few friends with a note saying ``run this script''. They did, and were duly rewarded. However, the script also looked through their mail alias file to see who their friends were, and auto-forwarded itself to them. They followed the instructions, too -- after all, the mail really did come from a login they trusted -- note carefully; the mail was from the *login*, not the person, except in the very first instance. The resulting mail storm amounted to a denial of service of attack on IBM's internal corporate network; they had to shut down the net to be able to clean up the mess. From Firewalls-Owner@GreatCircle.COM Tue Jan 11 23:49:31 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23930; Tue, 11 Jan 94 23:49:31 GMT Received: from brolga.cc.uq.oz.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23923; Tue, 11 Jan 94 15:49:22 PST Received: from cc.uq.oz.au by brolga.cc.uq.oz.au id <28074-0@brolga.cc.uq.oz.au>; Wed, 12 Jan 1994 09:50:06 +1000 Date: Wed, 12 Jan 1994 09:49:11 +1000 (EST) From: "Mark I. Williams" Subject: Re: How I can ftp kerberos from Russia? To: Bernhard.Schneck@Physik.TU-Muenchen.DE Cc: firewalls@GreatCircle.COM In-Reply-To: <199401111058.AA03098@srv.cip.physik.tu-muenchen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Someone mentioned that export of DES code (or anything else considered > munitions by the US government) from any country which has signed the > COCOM treaty should be governed by the US laws ... (I'm not sure if > this is really true, can't imagine any sovereign country would accept > such a clause! But COCOM does help a lot in trade with the US, so > maybe it's true anyway) Wasn't COCOM disbanded a month or so ago? (Does it make any difference?) cheers, Mark Williams The University of Queensland miw@cc.uq.edu.au +61 7 36 54012 (w) Prentice Centre +61 7 36 54477 (fax) Qld 4072 Australia sero venientibus ossa From Firewalls-Owner@GreatCircle.COM Wed Jan 12 01:20:29 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24561; Wed, 12 Jan 94 01:20:29 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24552; Tue, 11 Jan 94 17:20:16 PST Message-Id: <9401120120.AA24552@mycroft.GreatCircle.COM> To: "Mark I. Williams" Cc: Bernhard.Schneck@Physik.TU-Muenchen.DE, firewalls@GreatCircle.COM Subject: Re: How I can ftp kerberos from Russia? In-Reply-To: Your message of Wed, 12 Jan 1994 09:49:11 +1000 (EST) Date: Tue, 11 Jan 1994 17:20:15 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Mark I. Williams" writes: # > Someone mentioned that export of DES code (or anything else considered # > munitions by the US government) from any country which has signed the # > COCOM treaty should be governed by the US laws ... (I'm not sure if # > this is really true, can't imagine any sovereign country would accept # > such a clause! But COCOM does help a lot in trade with the US, so # > maybe it's true anyway) # # Wasn't COCOM disbanded a month or so ago? (Does it make any difference?) This is getting kind of off-track for the Firewalls mailing list... -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Wed Jan 12 01:30:11 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24687; Wed, 12 Jan 94 01:30:11 GMT Received: from cert.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22844; Tue, 11 Jan 94 10:28:08 PST Received: from mickey.cert.org by cert.org (4.1/cert-5.2) id AA25072; Tue, 11 Jan 94 13:31:22 EST Received: from localhost.cert.org by mickey.cert.org (4.1/cert-5.3) id AA27832; Tue, 11 Jan 94 13:31:20 EST Message-Id: <9401111831.AA27832@mickey.cert.org> To: Marcos Della Cc: firewalls@greatcircle.com Subject: Re: How to contact CERT... Date: Tue, 11 Jan 94 13:31:19 -0500 From: Georgia Killcrece Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Marcos, I'm so sorry, I neglected to include the FAQ in my reply :( By the way, so you don't have to read through the FAQ, you can send a request to cert-advisory-request@cert.org to be added to the advisory mailing list, and cert-tools-request@cert.org to be added to the cert-tools mailing list. You will receive confirmation, once your name has been added to the list(s). The FAQ is appended below. Again, please accept my apologies for any inconvenience! Regards, georgia Georgia Killcrece CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Internet E-mail: cert@cert.org Telephone: 412-268-7090 24-hour hotline: CERT personnel answer 8:30a.m.-5:00p.m. EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours. January 1993 Revision 7 JPO#93-025 and ESC#93-0115 The CERT Coordination Center FAQ ======================================================================= = Preface Section: = ======================================================================= This document is intended to answer the most Frequently Asked Questions (FAQs) about the CERT Coordination Center. The FAQ is a dynamic document that will change as information changes. Suggestions for additional sections are welcome -- please e-mail them to cert@cert.org. The most recent copy of this FAQ will be available via anonymous FTP from cert.org (192.88.209.5) in the /pub directory. Questions answered in this document A. Introduction to the CERT Coordination Center A1. What is CERT? A2. What does CERT stand for? B. Where to go for information B1. What is a CERT advisory? B2. Where can I obtain archived CERT advisories? B3. Can I obtain source code to a patch described in a CERT advisory? B4. What security mailing lists, newsgroups, and other sources of information does CERT recommend? B5. What information is available via anonymous FTP from CERT? B6. What presentations, workshops, and seminars does the CERT Coordination Center offer? B7. What books or articles does the CERT Coordination Center recommend? C. Incident Response C1. What kind of information should I provide to CERT when my site has experienced an intrusion? ======================================================================= = Section A. Introduction to the CERT Coordination Center = ======================================================================= A1. What is CERT? CERT is the Computer Emergency Response Team that was formed by the Defense Advanced Research Projects Agency (DARPA) in November 1988 in response to the needs exhibited during the Internet worm incident. The CERT charter is to work with the Internet community to facilitate its response to computer security events involving Internet hosts, to take proactive steps to raise the community's awareness of computer security issues, and to conduct research targeted at improving the security of existing systems. CERT products and services include 24-hour technical assistance for responding to computer security incidents, product vulnerability assistance, technical documents, and seminars. In addition, the team maintains a number of mailing lists (including one for CERT advisories) and provides an anonymous FTP server: cert.org (192.88.209.5), where security-related documents, past CERT advisories, and tools are archived. CERT contact information: U.S. mail address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 U.S.A. Internet E-mail address cert@cert.org Telephone number +1 412-268-7090 (24-hour hotline) CERT Coordination Center personnel answer 7:30 a.m.- 6:00 p.m. EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours. FAX number +1 412-268-6989 A2. What does CERT stand for? You may see our name in several different forms. CERT stood for "Computer Emergency Response Team", CERT/CC stood for "CERT Coordination Center", and now we use "CERT Coordination Center". Informally, we use "CERT", throughout this document and a few other documents. We use the e-mail address: cert@cert.org Any references to: cert@cert.sei.cmu.edu or cert@sei.cmu.edu should be changed to the new address (cert@cert.org). ======================================================================= = Section B. Where to go for information = ======================================================================= B1. What is a CERT advisory? A CERT advisory provides information on how to obtain a patch or details of a workaround for a known computer security problem. CERT works with vendors to produce a workaround or a patch for a problem, and does not publish vulnerability information until a workaround or a patch is available. A CERT advisory may also be a warning to our constituency about ongoing attacks (e.g., "CA-91:18.Active.Internet.tftp.Attacks"). CERT advisories are published on the USENET newsgroup: comp.security.announce and are distributed via the cert-advisory mailing list. Both of these publication methods are described below. CERT advisory archives are available via anonymous FTP from cert.org (192.88.209.5) in the /pub/cert_advisories directory. B2. Where can I obtain archived CERT advisories? CERT advisories are available via anonymous FTP from cert.org (192.88.209.5) in the /pub/cert_advisories directory. The "01-README" file provides a short summary of each of the advisories. B3. Can I get source code to a patch described in a CERT advisory? CERT does not provide source-level patches. Some vendors make source-level patches available to their source customers while others only distribute binary patches. Contact your vendor for more information. B4. What security mailing lists, newsgroups, and other sources of information does CERT recommend? (a) CERT mailing lists (1) CERT advisory mailing list The CERT Coordination Center maintains a CERT advisory mailing list for those members of the constituency who are unable to access USENET news or who would like to have advisories mailed directly to them or to a mail exploder at their site. If you would like to be added to the mailing list, please send mail to: cert-advisory-request@cert.org You will receive confirmation mail when you have been placed on the list. (2) CERT tools mailing list The purpose of this moderated mailing list is to encourage the exchange of information on security tools and techniques. The list should not be used for security problem reports. The CERT Coordination Center will not formally review, evaluate, or endorse the tools and techniques described. The decision to use the tools and techniques described is the responsibility of each user or organization, and we encourage each organization to thoroughly evaluate new tools and techniques before installation or use. Membership is restricted to system programmers, system administrators, and others with a legitimate interest in the development of computer security tools. If you would like to be considered for inclusion, please send mail to: cert-tools-request@cert.org You will receive confirmation mail when you have been placed on the list. (b) Other security-related mailing lists (1) VIRUS-L mailing list (see comp.virus newsgroup below) VIRUS-L is a moderated mailing list with a focus on computer virus issues. For more information, including a copy of the posting guidelines, see the file "virus-l.README", available via anonymous FTP on cert.org (192.33.209.5) in the /pub/virus-l directory. To be added to the mailing list, send mail to: listserv@lehigh.edu In the body of the message, put nothing more than: SUB VIRUS-L your name (2) VALERT-L mailing list VALERT-L is a mailing list for sharing urgent virus warnings among other computer users. Note that any message sent to VALERT-L will be cross-posted in the next VIRUS-l digest. To be added to the mailing list, send mail to: listserv@lehigh.edu In the body of the message, put nothing more than: SUB VALERT-L your name (c) USENET newsgroups (1) comp.security.announce The comp.security.announce newsgroup is moderated and is used solely for the distribution of CERT advisories. (2) comp.security.misc The comp.security.misc is a forum for the discussion of computer security, especially as it relates to the UNIX(r) Operating System. (3) alt.security The alt.security newsgroup is also a forum for the discussion of computer security, as well as other issues such as car locks and alarm systems. (4) comp.virus The comp.virus newsgroup is a moderated newsgroup with a focus on computer virus issues. For more information, including a copy of the posting guidelines, see the file "virus-l.README", available via anonymous FTP on cert.org (192.88.209.5) in the /pub/virus-l directory. (5) comp.risks The comp.risks newsgroup is a moderated forum on the risks to the public in computers and related systems. (d) NIST (National Institute of Standards and Technology) Computer Security Bulletin Board Information posted on the bboard includes an events calendar, software reviews, publications, bibliographies, lists of organizations, and other government bulletin board numbers. This bboard contains no sensitive (unclassified or classified) information. If you have any questions, contact NIST by phone at: 301-975-3359; by FAX at: 301-590-0932; or by e-mail at: csrc@csrc.ncsl.nist.gov. B5. What information is available via anonymous FTP from CERT? CERT provides information available via anonymous FTP from cert.org (192.88.209.5) in the /pub directory. In the /pub directory, the file "ls-lR" lists the subdirectories and the information found in those subdirectories. /pub/CERT_Press_Release_8812: The file "CERT_Press_Release_8812" is a copy of the December 1988 DARPA press release announcing the formation of the CERT Coordination Center. /pub/FIRST: The /pub/FIRST directory contains a file, "first-contacts". FIRST, the Forum of Incident Response and Security Teams, is an organization whose members work together voluntarily to deal with computer security problems and their prevention. General information on FIRST is available via anonymous FTP from csrc.ncsl.nist.gov in the /pub/first directory. The name of the file is "op_frame.txt". The document begins with a description of the CERT System, which was later renamed "FIRST". Also in that directory are the minutes from meetings, a list of FIRST contacts (also duplicated in the CERT anonymous FTP area on cert.org [192.88.209.5] in the /pub/FIRST directory), and other related information. /pub/cert_advisories: The /pub/cert_advisories directory contains archived copies of past CERT advisories, the "01-README" file, a copy of the CERT press release from December 1988 announcing the formation of CERT, an article from the March 1990 issue of Bridge, a magazine published by the Software Engineering Institute (SEI), describing CERT, and a file containing information on the status of the rdist patch. /pub/clippings: The /pub/clippings directory is an archive service for computer security. This archive is a central repository for selected security related USENET News and mailing list postings. The archive will not be restricted to any one newsgroup or mailing list. To submit an article for the clippings archive, please send e-mail to: clip@cert.org /pub/cops: The /pub/cops directory includes the information for the COPS package. COPS is a publicly available collection of programs that attempts to identify security problems in the UNIX Operating System. COPS does not attempt to correct any discrepancies found; it simply produces a report of its findings. /pub/info: The /pub/info directory contains online copies of security-related books and papers, including Dave Curry's May 1990 SRI Tech Report "Improving the Security of Your Unix System", "Computer Emergency Response - An International Problem" by Richard D. Pethia and Kenneth R. van Wyk, the report "Coping with the Threat of Computer Security Incidents: A Primer from Prevention through Recovery" by Russell Brand, and the Department of Defense Trusted Computer System Evaluation Criteria CSC-STD-001-83 often referred to as the "Orange Book". (Note: This is the Aug 1983 version of this document; this document was revised in Dec 1985.) /pub/network_tools The /pub/network_tools directory contains network tools made available via anonymous FTP. The file "tcp_wrapper.xx" is a TCP daemon wrapper program that will provide additional logging information and access control for many network services (also duplicated in the /pub/tools directory). /pub/papers: The /pub/papers directory contains the announcement of the CERT tools mailing list. /pub/ssphwg: The /pub/ssphwg directory contains archived information from the IETF Site Security Policy Handbook Working Group and the IETF Security Policy Working Group. RFC 1244, "Site Security Handbook" was the result of the Site Security Policy Handbook Working Group; and RFC 1281, "Guidelines for the Secure Operation of the Internet" was the result of the Security Policy Working Group. Both of these RFCs are available in the /pub/info directory, as mentioned above. /pub/tech_tips: The /pub/tech_tips directory contains documents on anonymous FTP configurations, packet filtering, and the CERT security checklist. /pub/tools: The /pub/tools directory contains various software programs, including COPS, Crack, TCP daemon wrappers, and virus-detection programs. /pub/virus-l: The /pub/virus-l directory contains the archives and other VIRUS-L and VALERT-L mailing list documents. B6. What presentations, workshops, and seminars does the CERT Coordination Center offer? (a) Presentations Throughout the year, members of the CERT Coordination Center give presentations at various technical conferences, seminars, and regional networks. Periodically, special arrangements can be made to tailor the presentation to fit the requirements of the specific site. For further information regarding presentations, please contact the CERT Coordination Center. (b) Workshops For the past few years, the CERT Coordination Center has hosted and co-sponsored the FIRST Workshop on Incident Handling. The 1993 workshop will be held in St. Louis, Missouri, August 10-13, 1993. For further information, please contact the CERT Coordination Center. (c) Seminars (1) Internet Security for Managers Description: This seminar is to help managers understand what needs to be done to ensure that their computer systems and networks are as securely managed as possible when operating within the Internet community. Attendees will be provided with information that will enable them to formulate realistic security policies, procedures, and programs specific to their operating environment. Audience: This seminar is designed for managers of computing centers/facilities, individuals tasked to evaluate/initiate Internet connectivity, senior system administrators, and others interested in computer security within the Internet community. (2) Internet Security for UNIX System Administrators Description: The information presented in this seminar is based on incidents reported to the CERT Coordination Center. The topics covered will include defensive and offensive strategies for system administration, site-specific security policies, and incident handling. Audience: This seminar is designed for users and system administrators of hosts using the UNIX Operating System. It is especially suited for system administrators of systems connected to a wide area network based on TCP/IP such as the Internet. Some system administrator experience is assumed. B7. What books or articles does the CERT Coordination Center recommend? [Bishop 87] Bishop, Matt. "How to Write a Setuid Program." ;login: 12(1) (Jan/Feb 1987): 5-12. [Curry 90] Curry, Dave. "Improving the Security of Your UNIX System" (Technical Report ITSTD-721-FR-90-21). Menlo Park, CA: SRI International, April 1990. [Curry 92] Curry, David A. UNIX System Security: A Guide for Users and System Administrators. Addison-Wesley Publishing Co., Inc. (ISBN 0-201-56327-4), 1992. [Denning 91] Denning, Peter J., ed. Computers Under Attack: Intruders, Worms, and Viruses. ACM Press, Addison-Wesley Publishing Company, Inc. (ISBN 0-201-53067-8), 1990. [Farrow 91] Farrow, Rik. How to Protect Your Data and Prevent Intruders: UNIX System Security. Addison-Wesley Publishing Company, Inc. (ISBN 0-201-57030-0), 1991. [Garfinkel and Spafford 91] Garfinkel, Simson; Spafford, Gene. Practical UNIX Security. O'Reilly & Associates, Inc. (ISBN 0-937175-72-2), 1991. [Grampo and Morris 84] Grampo, M.; Morris, R.T. "UNIX Operating System Security." AT&T Technical Journal 63(8) (Oct 1984): 1649-1672. [Hafner and Markoff 91] Hafner, Katie; Markoff, John. Cyperpunk: Outlaws and Hackers on the Computer Frontier. Simon & Schuster, 1991. [Morris and Thompson 79] Morris, R.T.; Thompson, K. "Password Security: A Case History." CACM 22(11) (November 1979): 594-597. [Nemeth, Snyder, and Seebass 89] Nemeth, Evi; Snyder, Garth; Seebass, Scott. UNIX System Administration Handbook. Prentice Hall (ISBN 0-13-933441-6), 1989. [Stoll 89] Stoll, Clifford. The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage. Doubleday (ISBN 0-385-24946-2), 1989. [Wood and Kochran 86] Wood, Patrick; Kochran, Stephen. UNIX System Security. Haden Books, 1986. ======================================================================= = Section C. Incident Response = ======================================================================= C1. What kind of information should I provide to CERT when my site has had an intrusion? The CERT Coordination Center would like as much information as possible, including opinions and thoughts as to how the breakin occurred. Some specifics include: 1) names of host(s) compromised at your site 2) architecture and OS (operating system and revision) of compromised host(s) 3) whether or not security patches have been applied to the compromised host(s); if so, were patches applied before or after the intrusion 4) account name(s) compromised 5) other host(s)/site(s) involved in the intrusion and whether or not you have already contacted those site(s) about the intrusion 6) if other site(s) have been contacted, the contact information used for contacting the site(s) involved 7) if CERT is to contact the other site(s), can we give the other sites your contact information (i.e., your name, e-mail address, and phone number) 8) whether or not any law enforcement agencies have been contacted 9) appropriate log extracts (including timestamps) 10) what assistance you would like from the CERT Coordination Center UNIX(r) is a registered trademark of UNIX System Laboratories, Inc. CERT is sponsored by the Advanced Research Projects Agency (ARPA). The Software Engineering Institute is sponsored by the U.S. Department of Defense. From Firewalls-Owner@GreatCircle.COM Wed Jan 12 05:02:01 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25447; Wed, 12 Jan 94 05:02:01 GMT Received: from deshaw.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25440; Tue, 11 Jan 94 21:01:47 PST Received: from cs2.deshaw.com by deshaw.com with SMTP id AA00480 (5.65c/IDA-1.4.4 for ); Tue, 11 Jan 1994 23:44:32 -0500 Message-Id: <199401120444.AA00480@deshaw.com> To: firewalls@greatcircle.com Subject: Re: Protocol level security and socks Date: Tue, 11 Jan 94 23:44:31 -0500 From: Mark Moraes Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk | # application/x-shar; sh %s This is a problem that's existed for a while -- there's too many shar's floating around the net (the UUCP maps, for instance, that some sites auto-unpack). I've used a secure unshar (for Unix) for quite a while -- it parses the shar itself rather than invoking sh. (chroot and unshar is a quicker way to achieve this, but I wanted this to run as non-root) (It's on ftp.cs.toronto.edu:/pub/moraes/unshar.tar.gz if anyone wants it. It'll unpack many shars, but not all -- people get very creative and stick uuencodes and so on in there) The notion of a system-call wrapper won't work with X if you're running Tcl/Tk applications -- Tk's "send" is a security-hole big enough to drive a truck through, a fact that John Ousterhout cheerfully pointed out at Dallas Usenix. Mark. From Firewalls-Owner@GreatCircle.COM Wed Jan 12 09:15:53 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26395; Wed, 12 Jan 94 09:15:53 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26388; Wed, 12 Jan 94 01:15:39 PST Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA07779; Wed, 12 Jan 94 01:17:10 PST Received: from UK.Sun.COM (sunuk) by snail.Sun.COM (4.1/SMI-4.1) id AA13660; Wed, 12 Jan 94 01:17:08 PST Received: from watchsun.UK.Sun.COM by UK.Sun.COM (4.1/SMI-4.1e-UK) id AA12005; Wed, 12 Jan 94 09:17:06 GMT Received: from zen.UK.Sun.COM by watchsun.UK.Sun.COM (4.1/SMI-5.0-sec(uk - sec)) id AA22772; Wed, 12 Jan 94 09:17:05 GMT Received: by zen.UK.Sun.COM (4.1/SMI-4.0) id AA14295; Wed, 12 Jan 94 09:17:05 GMT Date: Wed, 12 Jan 94 09:17:05 GMT From: Sean.Bennett@UK.Sun.COM (Sean Bennett - Sun UK - CS Hotline Engineer) Message-Id: <9401120917.AA14295@zen.UK.Sun.COM> To: firewalls@GreatCircle.COM Subject: IRC through SOCKS Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Does anyone know of an implementation of IRC that can run through SOCKS - for those of you that dont know IRC is a TCP app. protocol. Any ideas ? Sean From Firewalls-Owner@GreatCircle.COM Wed Jan 12 16:47:15 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27970; Wed, 12 Jan 94 16:47:15 GMT Received: from akasha.tic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27963; Wed, 12 Jan 94 08:47:07 PST Received: by akasha.tic.com (5.65/akasha.m4.1.14) id AA05350; Wed, 12 Jan 94 10:47:20 -0600 Message-Id: <9401121647.AA05350@akasha.tic.com> To: Mark Moraes Cc: firewalls@greatcircle.com, jsq@tic.com Subject: Re: Protocol level security and socks In-Reply-To: Your message of "Tue, 11 Jan 94 23:44:31 EST." <199401120444.AA00480@deshaw.com> Date: Wed, 12 Jan 94 10:47:18 -0600 From: jsq@tic.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > | # application/x-shar; sh %s > >This is a problem that's existed for a while -- there's too many shar's >floating around the net (the UUCP maps, for instance, that some sites >auto-unpack). I've used a secure unshar (for Unix) for quite a while -- it >parses the shar itself rather than invoking sh. (chroot and unshar is a >quicker way to achieve this, but I wanted this to run as non-root) There's also uuhosts; it still works. From Firewalls-Owner@GreatCircle.COM Wed Jan 12 09:48:33 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28222; Wed, 12 Jan 94 17:42:20 GMT Received: from hal.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28215; Wed, 12 Jan 94 09:42:08 PST Received: from gorn.hal.com by hal.com (4.1/SMI-4.1.1) id AA03463; Wed, 12 Jan 94 09:43:37 PST Received: by gorn.hal.com (4.1/SMI-4.1.2) id AA03983; Wed, 12 Jan 94 09:43:35 PST Date: Wed, 12 Jan 94 09:43:35 PST From: jonl@hal.com (frederick smythe, esquire) Message-Id: <9401121743.AA03983@gorn.hal.com> To: Sean.Bennett@UK.Sun.COM, firewalls@GreatCircle.COM Subject: Re: IRC through SOCKS Cc: socks@inoc.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk i've got a version of ircII 2.2.9 with SOCKS support. basically, it was no trouble to grab 2.2.9 and socksify it. FYI, this mail might have been more appropriate for the socks mailing list: socks@inoc.dl.nec.com i'm going to go ahead and CC that on this reply, and if a version doesn't exist somewhere, perhaps i'll upload the socksified src to the socks ftp archive. obviously, if anyone replies to this, direct it only to the socks list. --jon From Firewalls-Owner@GreatCircle.COM Thu Jan 13 04:16:53 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29958; Thu, 13 Jan 94 04:16:53 GMT Received: from ftp.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29950; Wed, 12 Jan 94 20:16:47 PST Received: from cucumbers.ftp.com by ftp.com with SMTP id AA12870; Wed, 12 Jan 94 23:16:27 -0500 Message-Id: <9401130416.AA12870@ftp.com> Date: Wed, 12 Jan 1994 23:16:14 EST From: hobbit@ftp.com (*Hobbit*) To: firewalls@greatcircle.com Subject: cute little scripts Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk David Koblas asks: How long until people start doing (when their friends send them "cute" little scripts...) application/x-shar; sh %s Fer that matter, how long before people start chrooting ALL their mail and FTP and WWW and gopher stuff out of hand, because it's so often full of stupid holes? I'm almost disgusted enough to do it at this point, but it's probably a good deal harder than one would think... _H* From Firewalls-Owner@GreatCircle.COM Thu Jan 13 18:35:17 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02873; Thu, 13 Jan 94 18:35:17 GMT Received: from gaia.electrum.kth.se by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02866; Thu, 13 Jan 94 10:35:07 PST Received: from localhost.electrum.kth.se by gaia.electrum.kth.se (5.61-bind 1.4+ida/4.0) id AA09713; Thu, 13 Jan 94 19:36:41 +0100 Message-Id: <9401131836.AA09713@gaia.electrum.kth.se> To: Firewalls@greatcircle.com Subject: Re: MIME questions In-Reply-To: Your message of Fri, 07 Jan 94 11:17:44 PST. <199401071917.AA00437@large.cisco.com> Date: Thu, 13 Jan 94 19:36:35 +0100 From: Christian Wettergren Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'll show my favorite "hidden feature" of popular viewers (this one is in *every* mailcap!); xv has the feature to do system() on the rest of the filename if it starts with a '!'. It was there in 2.21, and it's still there in 3.00. xv '!/tmp/na45362' perhaps? (oh well, not working) Now, I don't know whether it is possible to suggest a "special" tempname through a MIME-mail (although I think I have seen some name= switch?) but I wouldn't sleep well if I was running a firewall! Luckily, I'm not. ;-) /Christian Wettergren PS. WHY ON EARTH is there such a "feature"? From Firewalls-Owner@GreatCircle.COM Thu Jan 13 21:01:03 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03360; Thu, 13 Jan 94 21:01:03 GMT Received: from p-o.ans.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03353; Thu, 13 Jan 94 13:00:55 PST Received: by p-o.ans.net id AA15084 (5.65c/IDA-1.4.4 for Firewalls mailing list ); Thu, 13 Jan 1994 15:56:26 -0500 Message-Id: <199401132056.AA15084@p-o.ans.net> Date: Thu, 13 Jan 94 13:49:36 EST From: "Andrew T. Robinson" To: Firewalls mailing list Subject: Established connections--ACK vs. SYN bit Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk What are the ramifications of allowing established connections using the ACK instead of the SYN bit (the SYN bit is the one I've seen mentioned in this list more often (it seems))? Andy From Firewalls-Owner@GreatCircle.COM Fri Jan 14 15:30:37 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07791; Fri, 14 Jan 94 15:30:37 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07784; Fri, 14 Jan 94 07:30:27 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id HAA13989 for ; Fri, 14 Jan 1994 07:32:03 -0800 Message-Id: <199401141532.HAA13989@mailgate.cadence.com> Received: from mac31-206.cadence.com(158.140.31.206) by mailgate.cadence.com via smap (V1.0mjr) id sma013971; Fri Jan 14 07:31:52 1994 Date: Fri, 14 Jan 1994 07:31:49 -0800 To: firewalls@GreatCircle.COM From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: Established connections--ACK vs. SYN bit Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Andrew T. Robinson" writes: >What are the ramifications of allowing established connections using the ACK >instead of the SYN bit (the SYN bit is the one I've seen mentioned in this >list >more often (it seems))? > The following is off the top of my head, so people who know better, please correct me. SYN bit is set on the first packet in each direction only and is required to initialize the sequence numbers in the TCP communication. Therefore a packet without the SYN bit set belongs to an established connection. You therefore have to concentrate your filtering efforts on SYN packets only, which saves a lot of processing power in the router. The ACK bit is not always set. If your traffic flow is primarily one-way eg during a file transfer, many of the packets will not have the ACK bit set. If you drop or pass based on the ACK bit you will kill the connection. What I do is to log all the SYN packets, and spot which direction came first. The direction of the first is the direction of the connection, and this is invaluable for spotting "back-doors" ie services on high port numbers. It does produce a lot of false alarms as many applications produce "legitimate" inbound connections. Being beeped at 4am becuase someone in the Bombay office is using IRC is a real pain, I can tell you 8-(. I need to teach that perl script some fuzzy logic. Al My other Mac has my .sig --XAB28435.758532787/mailgate.cadence.com-- From Firewalls-Owner@GreatCircle.COM Fri Jan 14 16:00:54 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07926; Fri, 14 Jan 94 16:00:54 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07913; Fri, 14 Jan 94 08:00:41 PST Message-Id: <9401141600.AA07913@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Fri Jan 14 11:00:57 EST 1994 To: alastair@cadence.com (Alastair Young) Cc: firewalls@GreatCircle.COM Subject: Re: Established connections--ACK vs. SYN bit Date: Fri, 14 Jan 94 11:00:55 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The following is off the top of my head, so people who know better, please correct me. Well, you asked for corrections... SYN bit is set on the first packet in each direction only and is required to initialize the sequence numbers in the TCP communication. Therefore a packet without the SYN bit set belongs to an established connection. You therefore have to concentrate your filtering efforts on SYN packets only, which saves a lot of processing power in the router. The ACK bit is not always set. If your traffic flow is primarily one-way eg during a file transfer, many of the packets will not have the ACK bit set. If you drop or pass based on the ACK bit you will kill the connection. No. All TCP packets except the very first one of the connection have the ACK bit set. Here's how things work, when A is calling B: A->B: SYN, new (sort-of random) sequence numberA B->A: SYN, new (sort-of random) sequence numberB, ACK(A's seq #) A-B: ACK(B's seq #) That is, the initial packet from A has the ``synchronize sequence numbers'' bit set, and a new sequence number. B's reply has those two elements as well -- A doesn't know B's sequence number yet -- as well as an ACK for A's sequence number. A then ACK's B's new sequence number. Every subsequent packet from either side will always have the ACK bit set. If no traffic has been sent from the other side since the last acknowledgement, the sequence number being ACK'ed won't change, but it will still be there. In the above example, if B's initial sequence number was 100, and A sent a megabyte without B sending any data, every packet in that sequence will say ACK(100). The best reference for all this stuff is Richard Stevens' new book ``TCP/IP Illustrated''. He uses tcpdump to display packet traces for connections, so you can actually see this happening. (Disclaimer: I was a prepublication reviewer for Stevens' book, and he's reviewing mine, and we write for the same publisher.) This all relates to filtering because of the very first packet, the only one without the ACK bit set. It can't have ACK turned on, because A has no sequence number to acknowledge. A packet with a naked SYN is thus the first packet of a call, and therefore shows the direction of a call. A SYN+ACK is the second message of a connection. --Steve Bellovin From Firewalls-Owner@GreatCircle.COM Sun Jan 16 03:02:18 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15647; Sun, 16 Jan 94 03:02:18 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15499; Sat, 15 Jan 94 18:47:12 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id AAA20274 for ; Sat, 15 Jan 1994 00:34:02 -0800 Message-Id: <199401150834.AAA20274@mailgate.cadence.com> Received: from mac31-203.cadence.com(158.140.31.203) by mailgate.cadence.com via smap (V1.0mjr) id sma020247; Sat Jan 15 00:33:07 1994 Date: Sat, 15 Jan 1994 00:33:01 -0800 To: firewalls@greatcircle.com From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: Established connections--ACK vs. SYN bit Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > The following is off the top of my head, so people who know > better, please correct me. > >Well, you asked for corrections... > I feel enlightened! This will cure my false alarm problems. Does it also mean that my packet filters are wasting processing power on all those ACK/noSYN packets which it is going to pass anyway? Are such packets "harmless"? Calling jim@smallworks: would it improve performance in NetGate to just pass TCP packets with the ACK flag set? Al My other Mac has my .sig From Firewalls-Owner@GreatCircle.COM Sun Jan 16 05:16:38 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA16203; Sun, 16 Jan 94 05:16:38 GMT Received: from tamsun.tamu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA16196; Sat, 15 Jan 94 21:16:25 PST Received: by tamsun.tamu.edu id AA06746 (5.65b/IDA-1.4.3 for Firewalls@greatcircle.com); Sat, 15 Jan 94 23:17:34 -0600 Date: Sat, 15 Jan 94 23:17:34 -0600 Message-Id: <9401160517.AA06746@tamsun.tamu.edu> To: Firewalls@greatcircle.com From: remail@tamsun.tamu.edu Subject: WE'VE GOT TO *STOP* THE SQUISHING!! Remailed-By: Anonymous Comments: This message DID NOT originate from the address listed in the From line. It was remailed by an automated remailing service operating at that address. Please report problems by mailing to with the subject header of PROBLEM. Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk OFFICIAL ANNOUNCEMENT === ##### #### ## ## #### ##### ## ## ### ## ## ## ## ## ### ## ## #### ## ## ## ## ## #### ###### ### ## ## ## ## ## ### ## ## ##### ###\\ #### #### ##### ## ## ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Introducing the SYNCHRONIZED QUICK UNIFIED INTERNET SNAKE HUNT! * THOUSANDS OF CONTESTANTS * HUGE CASH PRIZES * * FASCINATING DISCOVERIES * HEDONISTIC DELIGHTS * * FANTASTIC FUN FOR EVERYONE * ENDLESS ENTERTAINMENT * CONTENTS ======== - INTRODUCTION - OBJECT OF SQUISH - A NOTE ABOUT YOUR OPPONENTS - UPDATES - THE CASH PRIZE - DEADLINE - MORE ABOUT `SQUISH' & `FACE' - QUESTIONS === The recent WHITE HOT interest by multiple groups and individuals in the CYBERANARCHIST TENTACLE INFILTRATIONS into the Internet have inspired an EXCITING NEW CONTEST and COMPETITION! we, the Federation of Associations of Cyberspace Everywhere (FACE), announce the SUPREMELY QUACKY UNIFIED INTERNET SNAKE HUNT! (SQUISH) * THOUSANDS OF CONTESTANTS * HUGE CASH PRIZES * * FASCINATING DISCOVERIES * HEDONISTIC DELIGHTS * * FANTASTIC FUN FOR EVERYONE * FAMOUS PARTICIPANTS * === OBJECT OF SQUISH the OBJECT of SQUISH is to find TENTACLES and SNAKES. A TENTACLE is an email address used by a real person for the purpose of concealing their identity from others. A SNAKE is a TENTACLE that is particularly wicked and evil and will lie and trick others into believing the TENTACLE is real. In words, the more consequential and malicious a TENTACLE, the more it is a SNAKE. Different points are awarded for playing. Anyone who can send mail can play! The simplest and cheapest points come from sending email to suspected SNAKES and TENTACLES, and chalking up points depending on the responses. When a snake or tentacle gets upset in response to mail, it is said to be QUIVERING. It will go through CONTORTIONS to convince you to leave it alone and may begin to SQUIRM if you persist. When people are not writing through fake email addresses, they are said to be using their TRUE NAME. TRUE NAMES may go through quivering, contortions, and squirming too. Some of the TRUE NAMES are BIG MACS and some are SMALL FRIES. Much larger points are awarded for exposing the BIG MACS, but some points are available for SMALL FRIES. BIG MACS are famous people on the Internet-- people that no one would expect have snakes and tentacles, or have media stories written about them. Matches take place in Cyberspace on the PLAYFIELD, with different regions consisting of INFECTED OUTLETS, CRIME SCENES, and KILLING FIELDS. A KILLING FIELD is a place where a tentacle and a player compete or a Big Mac is assaulted. INFECTED OUTLETS are media outlets or journals that carry BIG MAC propaganda, disinformation, or lies. The grand point prizes go to anyone who can expose MEDUSA. MEDUSA is the leader of all SMALL FRIES and BIG MACS, a wicked, evil incarnation of SATAN on the Internet. She is the originator and chief proseletyzer of the art, science, and religion of lies. MEDUSA has dozens of SNAKES all over the Internet, particularly in extremely sensitive areas such as Internet protocol development (e.g. mercantile or digital cash protocols), posting from public access sites and even `covers' and `front' sites, these are called POISON NEEDLES. * THOUSANDS OF CONTESTANTS * HUGE CASH PRIZES * * FASCINATING DISCOVERIES * HEDONISTIC DELIGHTS * * FANTASTIC FUN FOR EVERYONE * MYSTERIES OF THE UNKNOWN * A NOTE ABOUT YOUR OPPONENTS === Your opponents in SQUISH, are extremely sophisticated and have years of practice in the game, and have learned how to rebuff and thwart even the most determined inquiries. They have extremely powerful resources at their disposal, including cover stories and automated software for identity tracking, and sizeable investments in hardware. Beware of being humbled by the wizards. UPDATES === updates on the SQUISH contest will be posted regularly. Send in notice of the more spectacular point accumulations with proof for verifications immediately and the Halls of Fame and Shame. Unverified points are not valid toward the cash prize. THE CASH PRIZE === A cash prize will be awarded to the first person to surpass 500 points, one dollar per point. The person may continue playing to continue to gain cash. Further awards may be presented to close contenders. Some restrictions apply. Void where prohibited. Tax not included. In the case of deceased victims the award will be given to the nearest living relative, or the Federation of Associations of Cyberspace Everywhere (FACE) if all relatives have met mysterious fatal accidents as well. If the world economies have collapsed from cyberanarchist sabotage before the award is granted, no further action is necessary (this constitutes the final sign of the Apocalypse). DEADLINE === TIME IS RUNNING OUT! AVOID INQUIRING FURTHER OR WAITING FOR FURTHER INSTRUCTIONS. START IMMEDIATELY! MONTHS OF PARTICIPATION ARE REQUIRED TO ACCUMULATE COMPETITIVE STANDING. SOME PARTICIPANTS ALREADY HAVE A HEAD START. THE CASH PRIZE WILL BE AWARDED APRIL 1, 1994. FURTHER INCREMENTS WILL BE AWARDED AT YEARLY INTERVALS THEREAFTER. MORE ABOUT `SQUISH' AND `FACE' === The Federation of Associations of Cyberspace, Everywhere was founded in 1994 as a group that coordinates the activities among the many different online organizations. We have played a very low-profile role to date, and wanted to find some way of promoting our newfound alliance. We have groups combined from BBSes, local area networks, the Internet, and other global and local networks around the world (see below). We have built up some membership funds from the contributing organizations and private contributions to provide the prize money for SQUISH, and some private individuals have donated significant amounts. The contest was inspired by S.Boxx, who was the architect of point classifications and the current opponent lists. S.Boxx has also promised to provide any funds necessary for the successful completion of the contest. We hope that recent interest into snakes and tentacles by many on the Internet will make the contest spirited entertainment and a strong success. We encourage reporters and the media to use this announcement as our official press release. Feel free to redistribute or comment on this announcement in any forum. QUESTIONS === Address further questions to cypherpunks@toad.com, gnu@toad.com, tcmay@netcom.com, or hughes@ah.com. Some additional information is available in RISKS 15.25, 15.27, 15.28x: ftp CRVAX.SRI.COM, login anonymous, directory RISKS: (include the colon), file RISKS-i.j === ///// //// // // //// ///// // // /// // // // // // /// // // //// // // // // // //// ////// /// // // // // // /// // // ///// ///\\ //// //// ///// // // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Introducing the SALACIOUSLY QUIRKY UNIFIED INTERNET SNAKE HUNT! === Brought to you as a coordinated effort between the individuals * S.BOXX * MEDUSA * INFOCALYPSE * THE EXECUTIONER * PABLO ESCOBAR * DEADBEAT and the Federation of Associations of Cyberspace Everywhere (FACE) * ILF (INFORMATION LIBERATION FRONT) * BLACKNET (INTERNET ESPIONAGE COORDINATION HEADQUARTERS) * BLOODNET (CYBERSPATIAL BLACK MARKETEERING AND LIQUIDATION SQUAD) * CRAM (CYBERSPATIAL REALITY ADVANCEMENT MOVEMENT) * CRaP (CYBERANARCHIST REPRESSION AND POISON) * CY{B,PH}ER{PU,WO}NKS === * THOUSANDS OF CONTESTANTS * HUGE CASH PRIZES * * FASCINATING DISCOVERIES * HEDONISTIC DELIGHTS * * FANTASTIC FUN FOR EVERYONE * CRIMINAL CONVICTIONS * * GRISLY DEATH TORTURE * JUDGEMENT DAY * APOCALYPSE NOW * ------------------------------------------------------------------------- To find out more about this anonymous remail service, send mail to remail@tamsun.tamu.edu with the word "remail help" as the only words in the subject field. From Firewalls-Owner@GreatCircle.COM Sun Jan 16 21:22:28 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19862; Sun, 16 Jan 94 21:22:28 GMT Received: from cs.utexas.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19855; Sun, 16 Jan 94 13:22:20 PST Received: from im4u.cs.utexas.edu by cs.utexas.edu (5.64/1.22/mx-relay) with SMTP id AA12663; Sun, 16 Jan 94 15:24:00 -0600 Received: from chinaca by im4u.cs.utexas.edu (5.64/1.37/uucp) with UUCP id AA28407; Sun, 16 Jan 94 15:23:57 -0600 Received: from coldsnap.unicom.com by chinacat.unicom.com with smtp (smail3.1.28.1) id m0pLeud-0002NuC; Sun, 16 Jan 94 15:21 CST Received: from localhost by coldsnap.unicom.com (smail3.1.28.1) id m0pLeua-0002swC; Sun, 16 Jan 94 15:21 CST To: firewalls@greatcircle.com Newsgroups: local.maillist.firewalls Path: chip From: chip@chinacat.unicom.com (Chip Rosenthal) Subject: living with reverse DNS lookups Organization: Unicom Systems Development, Austin, TX Date: Sun, 16 Jan 1994 21:21:21 GMT Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Although I do not run a true firewall setup, Unicom.com does run seperate external and internal name services. The external name service merely provides the few hostnames that the outside world needs to know about. The creates a problem when doing anon ftp to a site that insists upon doing a DNS reverse lookup on the IN-ADDR.ARPA. When doing ftp from an internal workstation, one not listed in the DNS tables, the anon ftp site gets bitchy and refuses. I am thinking about adding a record that says: * IN PTR unspecified-hostname.unicom.com. at the END of my "105.108.192.in-addr.arpa" BIND datafile. The tests I've run on this seem to do the right thing. Can anybody come up with any reasons why this might create a problem? -- Chip Rosenthal 512-447-0577 | I figure the odds be fifty-fifty Unicom Systems Development | I just might have some thing to say. | -FZ From Firewalls-Owner@GreatCircle.COM Sun Jan 16 21:44:41 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19903; Sun, 16 Jan 94 21:44:41 GMT Received: from cpmx.saic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19896; Sun, 16 Jan 94 13:44:34 PST Message-Id: <9401162144.AA19896@mycroft.GreatCircle.COM> Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012d39b31d008488; Sun, 16 Jan 94 13:35:25 -0800 Date: 16 Jan 1994 13:31:59 -0800 From: "CPQM Admin" Subject: Re: Established connections- To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mail*Link(r) SMTP RE>Established connections- > The following is off the top of my head, so people who know > better, please correct me. > >Well, you asked for corrections... > I feel enlightened! This will cure my false alarm problems. Does it also mean that my packet filters are wasting processing power on all those ACK/noSYN packets which it is going to pass anyway? Are such packets "harmless"? Calling jim@smallworks: would it improve performance in NetGate to just pass TCP packets with the ACK flag set? Al My other Mac has my .sig ------------------ RFC822 Header Follows ------------------ Received: by cpqm.saic.com with SMTP;15 Jan 1994 20:33:10 -0800 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAvzav06216; Sat, 15 Jan 94 23:22:55 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15647; Sun, 16 Jan 94 03:02:18 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15499; Sat, 15 Jan 94 18:47:12 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id AAA20274 for ; Sat, 15 Jan 1994 00:34:02 -0800 Message-Id: <199401150834.AAA20274@mailgate.cadence.com> Received: from mac31-203.cadence.com(158.140.31.203) by mailgate.cadence.com via smap (V1.0mjr) id sma020247; Sat Jan 15 00:33:07 1994 Date: Sat, 15 Jan 1994 00:33:01 -0800 To: firewalls@GreatCircle.COM From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: Established connections--ACK vs. SYN bit Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From Firewalls-Owner@GreatCircle.COM Sun Jan 16 14:41:25 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20142; Sun, 16 Jan 94 22:39:02 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20133; Sun, 16 Jan 94 14:38:50 PST Message-Id: <9401162238.AA20133@mycroft.GreatCircle.COM> To: chip@chinacat.unicom.com (Chip Rosenthal) Cc: firewalls@greatcircle.com Subject: Re: living with reverse DNS lookups In-Reply-To: Your message of Sun, 16 Jan 1994 21:21:21 GMT Date: Sun, 16 Jan 1994 14:38:48 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk chip@chinacat.unicom.com (Chip Rosenthal) writes: # Although I do not run a true firewall setup, Unicom.com does run # seperate external and internal name services. The external name # service merely provides the few hostnames that the outside world # needs to know about. # # The creates a problem when doing anon ftp to a site that insists # upon doing a DNS reverse lookup on the IN-ADDR.ARPA. When doing ftp # from an internal workstation, one not listed in the DNS tables, the # anon ftp site gets bitchy and refuses. # # I am thinking about adding a record that says: # # * IN PTR unspecified-hostname.unicom.com. # # at the END of my "105.108.192.in-addr.arpa" BIND datafile. The # tests I've run on this seem to do the right thing. Can anybody # come up with any reasons why this might create a problem? I do this on most of the firewalls I build for clients, and it works just fine. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Sun Jan 16 23:52:50 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20593; Sun, 16 Jan 94 23:52:50 GMT Received: from mickey.ycc.yale.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20586; Sun, 16 Jan 94 15:52:41 PST Received: by mickey.ycc.yale.edu (5.0/SMI-SVR4) id AA14650; Sun, 16 Jan 94 18:49:55 EST Date: Sun, 16 Jan 1994 18:46:02 -0500 (EST) From: Elizabeth Kaufman Subject: Re: living with reverse DNS lookups To: Chip Rosenthal Cc: firewalls@GreatCircle.COM In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 651 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Sun, 16 Jan 1994, Chip Rosenthal wrote: > I am thinking about adding a record that says: > > * IN PTR unspecified-hostname.unicom.com. > > at the END of my "105.108.192.in-addr.arpa" BIND datafile. The > tests I've run on this seem to do the right thing. Can anybody > come up with any reasons why this might create a problem? That will work except where your target host does a double-reverse lookup. We use wildcard PTR records for our phonenet networks, and have found that there are a few ftp and WWW servers that refuse connectivity when the double-reverse lookup fails. -Elizabeth Kaufman Yale University Data Network Operations From Firewalls-Owner@GreatCircle.COM Mon Jan 17 00:15:05 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20643; Mon, 17 Jan 94 00:15:05 GMT Received: from brain.vifp.monash.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20634; Sun, 16 Jan 94 16:14:55 PST Received: from localhost (rik@localhost) by brain.vifp.monash.edu.au (8.6.5/8.6.5) id LAA11156; Mon, 17 Jan 1994 11:16:25 +1100 Message-Id: <199401170016.LAA11156@brain.vifp.monash.edu.au> To: firewalls@GreatCircle.COM Subject: Re: living with reverse DNS lookups In-Reply-To: Your message of "Sun, 16 Jan 1994 21:21:21 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Jan 1994 11:16:24 +1100 From: Rik Harris Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Although I do not run a true firewall setup, Unicom.com does run > seperate external and internal name services. The external name > service merely provides the few hostnames that the outside world > needs to know about. > > I am thinking about adding a record that says: > > * IN PTR unspecified-hostname.unicom.com. > > at the END of my "105.108.192.in-addr.arpa" BIND datafile. The > tests I've run on this seem to do the right thing. Can anybody > come up with any reasons why this might create a problem? I know of a couple of places around doing this, and think it is a useful tool. The only problem I can see is those few annoying services that do a reverse-forward lookup, and try and match 'unspecified-hostname.unicom.com.' to the same IP address as the connection. I think at least one ftp server does this. rik. -- The Fulcrum Consulting Group o ------------------------------------------------------------------------------ Rik Harris - rik.harris@fulcrum.com.au +61 3 621-2100 (BH) /\ 12th Floor, 10-16 Queen St. Melbourne VIC 3000. +61 3 621-2724 (Fax) From Firewalls-Owner@GreatCircle.COM Mon Jan 17 08:58:30 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA21683; Mon, 17 Jan 94 08:58:30 GMT Received: from millennium.tw.com (tw.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA21675; Mon, 17 Jan 94 00:58:19 PST Received: by millennium.tw.com (4.1/9999.1) id AA18918; Mon, 17 Jan 94 01:01:32 PST Date: Mon, 17 Jan 94 01:01:32 PST From: wadlow@tw.com (Tom Wadlow) Message-Id: <9401170901.AA18918@tw.com> To: firewalls@greatcircle.com Subject: Re: Protocol level security and socks Cc: brent@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk brent@GreatCircle.COM (Brent Chapman) writes: > What about a "-paranoid" option for GhostScript? Have it ask the user > for permission before doing any "dangerous" operation. I passed this question along to Peter Deutsch, the author of GhostScript, and he asked me to post the following in reply: Please pass on the following information to Firewalls: Ghostscript already has a -dSAFER option that prevents PostScript programs from writing, deleting, or renaming files. The one security hole that I know of in this scheme is that Ghostscript always searches the current directory for its initialization files before looking anywhere else. (The check is implemented in PostScript in an init file.) Once this is fixed, then assuming that MIME or Ghostview runs a known version of Ghostscript and can examine any command line switches that the user wants to pass it, I don't know of any way to circumvent the check. (The PostScript code is "sealed" in a way that makes the original definitions of the operators completely unavailable.) This security hole will be fixed in the forthcoming Ghostscript 3.0. Ghostscript 3.0 will also provide a way to compile the init files into the executable, creating an even more secure packaging option. From Firewalls-Owner@GreatCircle.COM Mon Jan 17 12:19:44 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22352; Mon, 17 Jan 94 12:19:44 GMT Received: from peking.gdwb.vic.gov.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22342; Mon, 17 Jan 94 04:19:04 PST Received: from cairo.gdwb.vic.gov.au by peking.gdwb.vic.gov.au with SMTP id AA24702 (5.65c/IDA-1.4.4); Mon, 17 Jan 1994 23:20:15 +1100 Received: by cairo.gdwb.vic.gov.au id AA07651 (5.65c/IDA-1.4.4); Mon, 17 Jan 1994 23:19:41 +1100 Date: Mon, 17 Jan 1994 23:19:41 +1100 From: Craig Bishop Message-Id: <199401171219.AA07651@cairo.gdwb.vic.gov.au> To: chip@chinacat.unicom.com, brent@greatcircle.com Subject: Re: living with reverse DNS lookups Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Date: Sun, 16 Jan 1994 14:38:48 -0800 From: Brent Chapman chip@chinacat.unicom.com (Chip Rosenthal) writes: # I am thinking about adding a record that says: # # * IN PTR unspecified-hostname.unicom.com. # # at the END of my "105.108.192.in-addr.arpa" BIND datafile. The # tests I've run on this seem to do the right thing. Can anybody # come up with any reasons why this might create a problem? I do this on most of the firewalls I build for clients, and it works just fine. It does work fine. We have been running this way for about 3 months. There is however a problem and that is the number of sites that do double reverse lookups is increasing. Everyone who installs tcp-wrappers in it's default configuration is another site you won't be able to contact. We are changing back to providing our DNS to the world. What harm can it do??? :-) Craig Bishop Information Systems Division Email: csb@gdwb.vic.gov.au Geelong & District Water Board Phone: +61 52 262506 61-67 Ryrie St Geelong Fax: +61 52 218236 Victoria 3220 Australia From Firewalls-Owner@GreatCircle.COM Mon Jan 17 16:11:07 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23004; Mon, 17 Jan 94 16:11:07 GMT Received: from uxc.cso.uiuc.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22997; Mon, 17 Jan 94 08:11:01 PST Received: by uxc.cso.uiuc.edu id AA17407 (5.67b8/IDA-1.5 for firewalls@greatcircle.com); Mon, 17 Jan 1994 10:12:15 -0600 Date: Mon, 17 Jan 1994 10:12:15 -0600 From: Paul Pomes Message-Id: <199401171612.AA17407@uxc.cso.uiuc.edu> To: firewalls@greatcircle.com Subject: Re: living with reverse DNS lookups Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The main UIUC ftp sites do a double reverse lookup and refuse connections in the case of mis-matches. We do this for almost all services on our central service hosts using the facilities provided by tcp_wrapper. I expect this type of service filtering to become more common, not less. Separate internal and external DNS servers provide next to nothing in terms of increased security. /pbp From Firewalls-Owner@GreatCircle.COM Mon Jan 17 16:27:20 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23081; Mon, 17 Jan 94 16:27:20 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23074; Mon, 17 Jan 94 08:27:13 PST Message-Id: <9401171627.AA23074@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Mon Jan 17 11:25:33 EST 1994 To: Paul Pomes Cc: firewalls@GreatCircle.COM Subject: Re: living with reverse DNS lookups Date: Mon, 17 Jan 94 11:25:32 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The main UIUC ftp sites do a double reverse lookup and refuse connections in the case of mis-matches. We do this for almost all services on our central service hosts using the facilities provided by tcp_wrapper. I expect this type of service filtering to become more common, not less. Indeed. It's worth noting that the standard SunOS resolvers do the cross-check lookup. Services that don't do it are vulnerable to various DNS games. Berkeley chose to add specific code to rlogind and rshd. Sun, having many services that depended on host names for authentication, chose -- correctly, in my opinion -- to put the check in one place. Separate internal and external DNS servers provide next to nothing in terms of increased security. Yes and no. The DNS data is a potent source of information for industrial espionage. It's also useful to hackers for target selection. From Firewalls-Owner@GreatCircle.COM Mon Jan 17 08:48:15 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23164; Mon, 17 Jan 94 16:42:47 GMT Received: from toe.CS.Berkeley.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23157; Mon, 17 Jan 94 08:42:38 PST Received: from localhost (hartzell@localhost) by toe.CS.Berkeley.EDU (8.6.4/8.1B) id IAA04071; Mon, 17 Jan 1994 08:44:20 -0800 Date: Mon, 17 Jan 1994 08:44:20 -0800 From: George Hartzell Message-Id: <199401171644.IAA04071@toe.CS.Berkeley.EDU> To: firewalls@GreatCircle.COM Subject: Re: living with reverse DNS lookups Reply-To: hartzell@cs.berkeley.edu (George Hartzell) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I don't think that double-reverse lookups should be a problem for sites using an application gateway for ftp (e.g. from tis' toolkit) if the gateway's name is registered. Am I correct? g. From Firewalls-Owner@GreatCircle.COM Mon Jan 17 08:48:49 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23156; Mon, 17 Jan 94 16:41:50 GMT Received: from uswat.advtech.uswest.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23149; Mon, 17 Jan 94 08:41:41 PST Received: from futureworld.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA01428 (5.67b/IDA-1.5 for ); Mon, 17 Jan 1994 09:43:21 -0700 Received: from localhost.uswest.com by futureworld.advtech.uswest.com (advtech.uswest.com) id AA07083 (4.1/at-generic.8Nov93); Mon, 17 Jan 94 09:43:19 MST Message-Id: <9401171643.AA07083@futureworld.advtech.uswest.com> To: alastair@cadence.com (Alastair Young) Cc: firewalls@greatcircle.com Subject: Re: Established connections--ACK vs. SYN bit In-Reply-To: Your message of "Sat, 15 Jan 1994 00:33:01 PST." <199401150834.AAA20274@mailgate.cadence.com> Date: Mon, 17 Jan 1994 09:43:19 -0700 From: Brad Huntting Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Does it also mean that my packet filters are wasting processing power on > all those ACK/noSYN packets which it is going to pass anyway? Are such > packets "harmless"? I'm not sure what else you can do with ACK/!SYN, but they do make fairly reliable pings... Just send an packet to port 25 (SMTP) with ACT set and SYN not set, and see if you get a packet back with RST set. brad From Firewalls-Owner@GreatCircle.COM Mon Jan 17 08:58:15 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23199; Mon, 17 Jan 94 16:49:08 GMT Received: from uucp-gw-2.pa.dec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23192; Mon, 17 Jan 94 08:48:59 PST Received: by uucp-gw-2.pa.dec.com; id AA28141; Mon, 17 Jan 94 08:46:04 -0800 Received: by netarch.com (4.1/SMI-4.1) id AA18795; Mon, 17 Jan 94 08:34:05 PST Date: Mon, 17 Jan 94 08:34:05 PST From: ming@netarch.com (Susan Chay) Message-Id: <9401171634.AA18795@netarch.com> X-Organization: Network Architecture Consulting, Fremont, CA To: firewalls@greatcircle.com Subject: Double reverse lookups Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi If anyone out there has code that implements double-reverse lookup of a name, could you please send me a code fragment that does that ? I need to do something like this but my version does not work too well. Thanks -s From Firewalls-Owner@GreatCircle.COM Mon Jan 17 09:19:11 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23314; Mon, 17 Jan 94 17:11:45 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23307; Mon, 17 Jan 94 09:11:36 PST Message-Id: <9401171711.AA23307@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Mon Jan 17 12:11:56 EST 1994 To: ming@netarch.com (Susan Chay) Cc: firewalls@GreatCircle.COM Subject: Re: Double reverse lookups Date: Mon, 17 Jan 94 12:11:55 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi If anyone out there has code that implements double-reverse lookup of a name, could you please send me a code fragment that does that ? I need to do something like this but my version does not work too well. Pick up rshd.c or rlogind.c from ftp.uu.net; they implement the code. Bind4.9.2 has a resolver that can do it, too, but that's not quite available yet. From Firewalls-Owner@GreatCircle.COM Mon Jan 17 11:38:16 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23923; Mon, 17 Jan 94 19:35:34 GMT Received: from uu6.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23916; Mon, 17 Jan 94 11:35:21 PST Received: from databus.UUCP by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA18909 for ; Mon, 17 Jan 94 14:14:31 -0500 Date: Mon, 17 Jan 94 14:14:31 -0500 Message-Id: <9401171914.AA18909@uu6.psi.com> From: Barney Wolff To: firewalls@greatcircle.com Subject: Re: double reverse lookup Content-Length: 523 Content-Type: text Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have no opportunity to try this, but why would it not work? Set up the DNS to respond to a reverse query with a unique hostname constructed from the IP address (such as h111222333444.domain or an encoded version of same). Then when the double reverse query comes, you can report back the same IP address, and all is well. What am I missing here? With a class C, I'd be tempted just to put all the entries in. I suppose somebody with a class A would have to hack the DNS code :-). Barney Wolff From Firewalls-Owner@GreatCircle.COM Mon Jan 17 20:55:40 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24073; Mon, 17 Jan 94 20:55:40 GMT Received: from seas.smu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24066; Mon, 17 Jan 94 12:55:33 PST Received: by seas.smu.edu (/\==/\ Smail3.1.28.1 #28.25) id ; Mon, 17 Jan 94 15:57 CDT Received: by seas.smu.edu (/\==/\ Smail3.1.28.1 #28.28 63.63.63.turbo_f) id ; Mon, 17 Jan 94 14:56 CST Message-Id: From: doug@seas.smu.edu (Doug Davis) Subject: Re: double reverse lookup To: barney@databus.com (Barney Wolff) Date: Mon, 17 Jan 1994 14:56:59 -0600 (CST) Cc: firewalls@GreatCircle.COM In-Reply-To: <9401171914.AA18909@uu6.psi.com> from "Barney Wolff" at Jan 17, 94 02:14:31 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 651 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > I have no opportunity to try this, but why would it not work? > > Set up the DNS to respond to a reverse query with a unique hostname > constructed from the IP address (such as h111222333444.domain or an > encoded version of same). Then when the double reverse query comes, > you can report back the same IP address, and all is well. What am I > missing here? > a double lookup does something like the following. s=getpeername(sd) /* gets the ip address of the socket */ hostname == dns_lookup(s->addr) /* get reverse entry name */ ip == dns_gethostip(hostname) /* get forward entry ip address */ if ip != s->addr reject connection. From Firewalls-Owner@GreatCircle.COM Mon Jan 17 23:43:11 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25229; Mon, 17 Jan 94 23:43:11 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25222; Mon, 17 Jan 94 15:43:01 PST Message-Id: <9401172343.AA25222@mycroft.GreatCircle.COM> Received: by coombs.anu.edu.au (1.37.109.8/16.2) id AA10707; Tue, 18 Jan 1994 10:46:27 +1100 From: Darren Reed Subject: Re: double reverse lookup To: doug@seas.smu.edu (Doug Davis) Date: Tue, 18 Jan 1994 10:46:27 +1000 (EDT) Cc: barney@databus.com, firewalls@GreatCircle.COM In-Reply-To: from "Doug Davis" at Jan 17, 94 02:56:59 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 866 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > > > > I have no opportunity to try this, but why would it not work? > > > > Set up the DNS to respond to a reverse query with a unique hostname > > constructed from the IP address (such as h111222333444.domain or an > > encoded version of same). Then when the double reverse query comes, > > you can report back the same IP address, and all is well. What am I > > missing here? > > > a double lookup does something like the following. > > > s=getpeername(sd) /* gets the ip address of the socket */ > hostname == dns_lookup(s->addr) /* get reverse entry name */ > ip == dns_gethostip(hostname) /* get forward entry ip address */ > > if ip != s->addr reject connection. This often is a problem with multihomed hosts, it'll have only one A record or the wrong A record in DNS and the connection to the service will come from the other IP#. Darren From Firewalls-Owner@GreatCircle.COM Mon Jan 17 23:54:21 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26530; Tue, 18 Jan 94 07:47:08 GMT Received: from esri.com (REDLANDS.ESRI.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26521; Mon, 17 Jan 94 23:46:59 PST Received: from universe ([192.9.155.1]) by esri.com (4.1/SMI-4.1) id AA06931; Mon, 17 Jan 94 17:27:55 PST Received: from arian.universe by universe (4.1/SMI-4.1) id AA02157; Mon, 17 Jan 94 17:26:20 PST Comment: Environmental Systems Research Institute Received: by arian.universe (4.1/SMI-4.1) id AA10805; Mon, 17 Jan 94 17:28:07 PST Date: Mon, 17 Jan 94 17:28:07 PST From: hsafai@esri.com (Houman Safai ) Message-Id: <9401180128.AA10805@arian.universe> To: sun-managers-relay@ra.mcs.anl.gov Subject: Telnet/Ftp through a firewall Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi Managers, I am looking for a product that will allow users to telnet or ftp directly from their workstations to the internet without first logging on the internet machine? There was a recent posting on a product that has such capability but unfortunately, I have misplaced the email. Any information will be greatly appreciated. Houman Safai hsafa@esri.com Unix Systems Administrator 380 New York St. Redlands, Ca 92373 From Firewalls-Owner@GreatCircle.COM Tue Jan 18 00:04:22 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26729; Tue, 18 Jan 94 07:57:02 GMT Received: from hal.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26716; Mon, 17 Jan 94 23:56:53 PST Received: from gorn.hal.com by hal.com (4.1/SMI-4.1.1) id AA07305; Mon, 17 Jan 94 21:50:06 PST Received: by gorn.hal.com (4.1/SMI-4.1.2) id AA15467; Mon, 17 Jan 94 21:50:06 PST Date: Mon, 17 Jan 94 21:50:06 PST From: jonl@hal.com (frederick smythe, esquire) Message-Id: <9401180550.AA15467@gorn.hal.com> To: firewalls@greatcircle.com Subject: udprelay & archie Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk i'm trying to toss udprelay up and use archie/xarchie as a client to verify it works. the udprelay seems to be listening just fine, and the client seems to be sending to the right place, yet the relayer doesn't seem to be noticing it. i'm sort of overwhelmed with other work right now, so i'm hoping that i can glean some pointers from other people before having to spend time and peruse through the source. please reply to me, as this isn't really appropriate for another thread on the firewalls list. (i apologize for bringing it up, having done so since this is where i originally got info about udprelay). -- jon r. luini, jonl@hal.com (408) 379-7000, x1276 From Firewalls-Owner@GreatCircle.COM Tue Jan 18 08:42:49 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26997; Tue, 18 Jan 94 08:42:49 GMT Received: from shadow.net (anshar.shadow.net) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26989; Tue, 18 Jan 94 00:42:40 PST Received: from localhost (jc@localhost) by shadow.net (8.6.4/jc-1.0) id TAA27314; Mon, 17 Jan 1994 19:36:31 -0500 Date: Mon, 17 Jan 1994 19:32:45 -0500 (EST) From: Justin Subject: Re: Double reverse lookups To: Susan Chay Cc: firewalls@GreatCircle.COM In-Reply-To: <9401171634.AA18795@netarch.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Mon, 17 Jan 1994, Susan Chay wrote: > Hi > > If anyone out there has code that implements double-reverse lookup of > a name, could you please send me a code fragment that does that ? > > I need to do something like this but my version does not work too well. > > Thanks > > -s There is a software package called "resolv+" with an option that can be specified in /etc/host.conf called "nospoof". When a user of my network attempts to resolve a name, it takes the resulting IP address and does a reverse lookup to obtain the name again. If the two don't match, its evidence of DNS spoofing. You should be able to find the routines you need out of this package. -jc From Firewalls-Owner@GreatCircle.COM Tue Jan 18 09:34:39 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27195; Tue, 18 Jan 94 09:34:39 GMT Received: from mail.Germany.EU.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27188; Tue, 18 Jan 94 01:34:31 PST Received: by mail.Germany.EU.net(EUnetD-2.3.1.c) via EUnet id dW23326; Tue, 18 Jan 1994 10:37:04 +0100 Message-Id: <199401180937.KAA24132@halo.Germany.EU.net> Received: from localhost.Germany.EU.net by halo.Germany.EU.net with SMTP (8.6.4/EUnetDlan-1.4-1.1.4) via EUnet for [mail.germany.eu.net] id KAA24132; Tue, 18 Jan 1994 10:37:04 +0100 To: firewalls@greatcircle.com From: John Murray Subject: Re: living with reverse DNS lookups In-Reply-To: Message of Mon, 17 Jan 1994 10:12:15 -0600. <199401171612.AA17407@uxc.cso.uiuc.edu> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Date: Tue, 18 Jan 1994 10:37:01 +0100 Sender: John.Murray@Germany.EU.net Hi People, > Separate internal and external DNS servers provide next to nothing in > terms of increased security. > > /pbp Wait a second, from some people I here the argument: intern/extern DNS is a must for secure sites. ( otherwise you provide a map of your internal net) While others seem to say: it dosen't matter the info is useless. (if you take other precautions) Opinions? Cheers!! John From Firewalls-Owner@GreatCircle.COM Tue Jan 18 10:30:35 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27621; Tue, 18 Jan 94 10:30:35 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27614; Tue, 18 Jan 94 02:30:26 PST Message-Id: <9401181030.AA27614@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Mon Jan 17 19:31:07 EST 1994 To: Darren Reed Cc: doug@seas.smu.edu (Doug Davis), barney@databus.com, firewalls@GreatCircle.COM Subject: Re: double reverse lookup Date: Mon, 17 Jan 94 19:31:07 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This often is a problem with multihomed hosts, it'll have only one A record or the wrong A record in DNS and the connection to the service will come from the other IP#. You have to be careful about how you set up your DNS, and how you write your code. First, the code has to check all A records for a given name, not just one. Second, you have to be sure that your DNS is set up so that if a PTR record yields a particular name, then that name has that address as one of its A records. This still gives you a lot of flexibility. You could, for example, say things like this: name IN A 10.1.0.1 IN A 10.2.0.1 name1 IN A 10.1.0.1 name2 IN A 10.2.0.1 1.0.1.10.in-addr.arpa IN PTR name1 1.0.2.10.in-addr.arpa IN PTR name2 That way, attempts to call you get 2 A records, but each PTR record points to an A record unique to that address. My preferred configuration is this: name IN A 10.1.0.1 IN A 10.2.0.1 name1 IN A 10.1.0.1 name2 IN A 10.2.0.1 1.0.1.10.in-addr.arpa IN PTR name 1.0.2.10.in-addr.arpa IN PTR name so that all addresses map back to the real name, but I have alternate forward references -- which aren't cross-checked -- if you need to address the host by a particular name. From Firewalls-Owner@GreatCircle.COM Tue Jan 18 11:06:11 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27696; Tue, 18 Jan 94 11:06:11 GMT Received: from apple.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27689; Tue, 18 Jan 94 03:06:03 PST Received: by apple.com (5.61/8-Oct-1993-eef) id AA05401; Tue, 18 Jan 94 02:42:52 -0800 Received: by wattres.SJ.CA.US id AA00138 (5.65c/IDA-1.4.4); Tue, 18 Jan 1994 02:23:26 -0800 Date: Tue, 18 Jan 1994 02:23:26 -0800 From: Steve Watt -- KD6GGD Message-Id: <199401181023.AA00138@wattres.SJ.CA.US> To: firewalls@greatcircle.com, doug@seas.smu.EDU Newsgroups: local.firewalls In-Reply-To: References: <9401171914.AA18909@uu6.psi.com> Organization: Steven Watt, Consultant San Jose, CA, USA Subject: Re: double reverse lookup Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In article doug@seas.smu.EDU wrote: >> Set up the DNS to respond to a reverse query with a unique hostname >> constructed from the IP address (such as h111222333444.domain or an >> encoded version of same). Then when the double reverse query comes, >> you can report back the same IP address, and all is well. What am I >> missing here? Not missing much, but part of the theory of not publishing all of your DNS records to the outside world is to lower the number of systems whose IP addresses are instantly guessable. It's the "need-to-know" school of thought. The whole 'net doesn't need to know what all your internal hosts are, so why tell them? Of course, there are some reasons to tell, too. Most of them have to do with buggy software on the outside. >a double lookup does something like the following. > >s=getpeername(sd) /* gets the ip address of the socket */ >hostname == dns_lookup(s->addr) /* get reverse entry name */ >ip == dns_gethostip(hostname) /* get forward entry ip address */ > >if ip != s->addr reject connection. Well, it's almost right. The TIS toolkit (and probably others) misses one little point: Multi-homed hosts. If you have a system with 2 or 3 or more A records, even if the PTR records are all there, if you don't check EACH A record you get back, you'll reject a perfectly good system. A more correct pseudocode might be: peeraddr = getpeername(socket) hostname = gethostbyname(peeraddr) iplist = gethostbyaddr(hostname) for addr in iplist { if peeraddr == addr matched it } if !matched blow off connection Steve -- Steve Watt KD6GGD Packet: KD6GGD @ N0ARY.#NOCAL.CA.USA.NA ICBM: 121W 56' 53.1" / 37N 20' 16.7" Internet: Home: steve@wattres.SJ.CA.US "I am always ready to learn, although I Work: swatt@lynx.com don't always like being taught." -- Winston Churchill From Firewalls-Owner@GreatCircle.COM Tue Jan 18 06:24:23 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28038; Tue, 18 Jan 94 14:18:52 GMT Received: from p-o.ans.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28026; Tue, 18 Jan 94 06:18:41 PST Received: by p-o.ans.net id AA11439 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Tue, 18 Jan 1994 09:14:05 -0500 Message-Id: <199401181414.AA11439@p-o.ans.net> Date: Tue, 18 Jan 94 09:11:25 EST From: "Andrew T. Robinson" To: firewalls@greatcircle.com Subject: Re: double reverse lookup Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In my last message, I wrote: >... someone did ask for opions For the laymen in the audience, opions are a new class of subatomic particle which are responsible for strangeness (a strange quark is just a superstring with an opion at one end). Andy From Firewalls-Owner@GreatCircle.COM Tue Jan 18 14:25:41 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28067; Tue, 18 Jan 94 14:25:41 GMT Received: from roxi.rz.fht-mannheim.de by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28057; Tue, 18 Jan 94 06:25:28 PST Received: by roxi.rz.fht-mannheim.de id AA18426 (5.67b8/IDA-1.5 for firewalls@greatcircle.com); Tue, 18 Jan 1994 15:26:50 +0100 Message-Id: <199401181426.AA18426@roxi.rz.fht-mannheim.de> Subject: Re: double reverse lookup To: firewalls@greatcircle.com Date: Tue, 18 Jan 1994 15:26:50 +0100 (MEZ) From: Martin Rex In-Reply-To: from "Doug Davis" at Jan 17, 94 02:56:59 pm Reply-To: Martin_Rex@rz.fht-mannheim.de Content-Type: text Content-Length: 775 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ... Doug Davis wrote: > > s=getpeername(sd) /* gets the ip address of the socket */ > hostname == dns_lookup(s->addr) /* get reverse entry name */ > ip == dns_gethostip(hostname) /* get forward entry ip address */ > > if ip != s->addr reject connection. You should be prepared to get more than one address returned when looking up a hostname, because there are machines that have several network interfaces, and there are DNS setups which reflect this (rather than using different hostnames for the same machine, depending on the referenced interface). So you ought to check all addresses that are returned. -Martin -- Martin Rex Rechenzentrum, Netzwerk- und Systemadministration (Unix) Fachhochschule fuer Technik Mannheim E-Mail: mrex@rz.fht-mannheim.de From Firewalls-Owner@GreatCircle.COM Tue Jan 18 06:34:23 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28040; Tue, 18 Jan 94 14:18:52 GMT Received: from p-o.ans.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28025; Tue, 18 Jan 94 06:18:41 PST Received: by p-o.ans.net id AA11435 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Tue, 18 Jan 1994 09:14:01 -0500 Message-Id: <199401181414.AA11435@p-o.ans.net> Date: Tue, 18 Jan 94 08:53:22 EST From: "Andrew T. Robinson" To: firewalls@greatcircle.com Subject: Re: double reverse lookup Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm one of the least qualified to render an opinion, but someone did ask for opions: If I understand everything I've read, split-universe DNS doesn't seem to be worth the trouble: * Potential loss of access to services which rely on double-reverse lookups * Increased administrative complexity--most DNS servers were apparently not designed with split DNS in mind, and split DNS solutions SEEM (wrong?) to rely on the behavior of certain implementations of DNS servers and name resolvers. On the other hand, the idea of split DNS is intuitively attractive to me for a reason entirely separate from security: since you are only advertising one or a few hosts (instead of hundreds or thousands) which are accessible to the public Internet, it's easier for people to access services you may choose to provide. If there is now or in the future a method to provide "clean" split DNS without sacrificing access due to double-reverse lookups, I'd implement it. Right now I would (have in fact) advise omitting split DNS from a firewall setup, with the qualification that some/most of the foremost security experts on the Internet recommend it. Andy From Firewalls-Owner@GreatCircle.COM Tue Jan 18 08:17:34 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28489; Tue, 18 Jan 94 16:10:31 GMT Received: from uswat.advtech.uswest.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28482; Tue, 18 Jan 94 08:10:22 PST Received: from futureworld.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA21207 (5.67b/IDA-1.5 for ); Tue, 18 Jan 1994 09:11:47 -0700 Received: from localhost.uswest.com by futureworld.advtech.uswest.com (advtech.uswest.com) id AA10618 (4.1/at-generic.8Nov93); Tue, 18 Jan 94 09:11:35 MST Message-Id: <9401181611.AA10618@futureworld.advtech.uswest.com> To: John Murray Cc: firewalls@greatcircle.com Subject: Re: living with reverse DNS lookups In-Reply-To: Your message of "Tue, 18 Jan 1994 10:37:01 +0100." <199401180937.KAA24132@halo.Germany.EU.net> Date: Tue, 18 Jan 1994 09:11:35 -0700 From: Brad Huntting Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Wait a second, from some people I here the argument: > intern/extern DNS is a must for secure sites. > ( otherwise you provide a map of your internal net) > While others seem to say: > it dosen't matter the info is useless. > (if you take other precautions) > Opinions? DNS is the first place to look when one starts cracking a site. If DNS provides little or no usefull information then it has given your security a small but significant boost. This is especially true of lazy crackers (small fry). If they cant see anything interesting, then they will probably turn their attentions tward other, more open sites. If on the other hand, the cracker knows what he or she is after, then hiding DNS will probably not help nearly as much. brad From Firewalls-Owner@GreatCircle.COM Tue Jan 18 11:07:48 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29071; Tue, 18 Jan 94 19:01:48 GMT Received: from uu6.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29064; Tue, 18 Jan 94 11:01:34 PST Received: from databus.UUCP by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA15067 for ; Tue, 18 Jan 94 13:37:32 -0500 Date: Tue, 18 Jan 94 13:37:32 -0500 Message-Id: <9401181837.AA15067@uu6.psi.com> From: Barney Wolff To: Steve Watt -- KD6GGD , firewalls@greatcircle.com, doug@seas.smu.EDU Subject: Re: double reverse lookup Content-Length: 1749 Content-Type: text Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From: Steve Watt -- KD6GGD > >In article doug@seas.smu.EDU wrote: Actually, I wrote it, and Doug was replying. >>> Set up the DNS to respond to a reverse query with a unique hostname >>> constructed from the IP address (such as h111222333444.domain or an >>> encoded version of same). Then when the double reverse query comes, >>> you can report back the same IP address, and all is well. What am I >>> missing here? > >Not missing much, but part of the theory of not publishing all of your >DNS records to the outside world is to lower the number of systems whose >IP addresses are instantly guessable. It's the "need-to-know" school of >thought. The whole 'net doesn't need to know what all your internal hosts >are, so why tell them? I don't think you're telling them anything, as the hostname is a fake, and can be reported for every IP address in your network, not just for hosts that actually exist. I believe code that tries name.domain-->IP-->name.domain and insists on a match is simply wrong, as hosts can legitimately have aliases, which will fail this test. But the double-reverse lookup is IP-->name.domain-->IP, which can always be made to work if name.domain depends uniquely on IP. This tells the world nothing, as if the querier is checking the IP address because it just got a packet from that address, the querier already knows that there is a host at that address. If the querier is probing for hosts, it gets nothing useful provided the name server returns a name.domain for every IP address in its network. I can find out who owns a network from the top-level in-addr.arpa servers, so nothing extra is being revealed here. Barney Wolff From Firewalls-Owner@GreatCircle.COM Tue Jan 18 11:26:33 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29144; Tue, 18 Jan 94 19:17:45 GMT Received: from wd40.ftp.com (ftp.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29137; Tue, 18 Jan 94 11:17:35 PST Received: from cucumbers.ftp.com by wd40.ftp.com ; Tue, 18 Jan 1994 14:19:20 -0500 Message-Id: <9401181919.AA17785@wd40.ftp.com> Date: Tue, 18 Jan 1994 14:19:17 EST From: hobbit@wd40.ftp.com (*Hobbit*) To: firewalls@greatcircle.com Subject: dns spoofola Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Lots of packages do inverse and then forward DNS lookup in an attempt to detect spoofing. A good effort, but ... Suppose someone intent on no good set a packet generator of some sort to firing lots of DNS replies with the responsible nameserver's source address and containing spoofed information, both PTR and A, at the target machine? Chances seem good that the spoof DNS replies would get in there before the real reply just when the target machine tried to do the lookups, and then access would be granted to the spoofer's client address... _H* From Firewalls-Owner@GreatCircle.COM Tue Jan 18 12:57:28 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29504; Tue, 18 Jan 94 20:48:47 GMT Received: from world.std.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29497; Tue, 18 Jan 94 12:48:39 PST Received: by world.std.com (5.65c/Spike-2.0) id AA23502; Tue, 18 Jan 1994 15:50:22 -0500 Date: Tue, 18 Jan 1994 15:50:21 -0500 (EST) From: Ann Weigold Subject: firewalls To: firewalls@greatcircle.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Can anyone recommend some reading regarding How to set up a firewall? Thanks, Ann Weigold From Firewalls-Owner@GreatCircle.COM Wed Jan 19 07:31:59 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01802; Wed, 19 Jan 94 07:31:59 GMT Received: from dalkey.hea.ie by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01795; Tue, 18 Jan 94 23:31:45 PST Received: from localhost by dalkey.hea.ie (5.65/Ultrix3.0-C) id AA19054; Wed, 19 Jan 1994 07:32:54 GMT Message-Id: <9401190732.AA19054@dalkey.hea.ie> To: Ann Weigold Cc: firewalls@greatcircle.com Subject: Re: firewalls In-Reply-To: Your message of "Tue, 18 Jan 94 15:50:21 EST." Date: Wed, 19 Jan 94 07:32:54 +0000 From: "Mike Norris" X-Mts: smtp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk How about "Practical Unix Security" by Garfinkel and Spafford (O'Reilly & Associates, Inc.) ISBN 0-937175-72-2. Mike Norris From Firewalls-Owner@GreatCircle.COM Wed Jan 19 16:30:08 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03379; Wed, 19 Jan 94 16:30:08 GMT Received: from symbi1.symbiosis.ahp.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03364; Wed, 19 Jan 94 08:29:57 PST From: aem@symbi1.symbiosis.ahp.com (a.e.mossberg) Received: from localhost (aem@localhost) by symbi1.symbiosis.ahp.com id LAA03717; Wed, 19 Jan 1994 11:29:27 -0500 Message-Id: <199401191629.LAA03717@symbi1.symbiosis.ahp.com> Subject: Netblazer filter configuration To: firewalls@greatcircle.com Date: Wed, 19 Jan 1994 11:29:27 -0500 (EST) X-Hpvue$Revision: 1.8 $ X-Vue-Mime-Level: 4 X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 749 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm having some trouble getting the netblazer's filter to behave the way I want, and Telebit still has not responded to my call from last friday. What am I doing wrong here? ip filter deny CLA.SSC.NET/24 outside dest out deny CLA.SSC.NET/24 outside source in permit CLA.SSC.NET.AHOST/32 outside icmp permit CLA.SSC.NET/24 outside udp 7-19 53 123 520 dest out permit CLA.SSC.NET/24 outside udp 7-19 53 123 520 source in permit CLA.SSC.NET/24 outside tcp 25 53 113 119 >1023 !=2049 !=6000 dest out permit CLA.SSC.NET/24 outside tcp 20-25 !=22 !=24 53 113 119 >1023 !=2049 !=6000 source in thanks, aem -- andrew mossberg * symbiosis corporation * miami florida * 305-597-4110 fax: (305) 597-4002 * MD5OfPublicKey: 15784D117CC103912AEC427A3A99BA83 From Firewalls-Owner@GreatCircle.COM Wed Jan 19 16:38:55 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03415; Wed, 19 Jan 94 16:38:55 GMT Received: from esri.com (REDLANDS.ESRI.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03408; Wed, 19 Jan 94 08:38:44 PST Received: from universe ([192.9.155.1]) by esri.com (4.1/SMI-4.1) id AA01778; Wed, 19 Jan 94 08:40:38 PST Received: from arian.universe by universe (4.1/SMI-4.1) id AA04304; Wed, 19 Jan 94 08:39:08 PST Comment: Environmental Systems Research Institute Received: by arian.universe (4.1/SMI-4.1) id AA13457; Wed, 19 Jan 94 08:40:51 PST Date: Wed, 19 Jan 94 08:40:51 PST From: hsafai@esri.com (Houman Safai ) Message-Id: <9401191640.AA13457@arian.universe> To: svu@esri.com Subject: Summary:Telnet/Ftp through a firewall Cc: Robert.Bethel@CBIS.Com, firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello Managers, I can always depend on this list. Thanks for all the responses. Most people recommended using the TIS FIrewall Toolkit(fwtk). I have downloaded a copy from the net and will be working on it this week. My original questions was: > I am looking for a product that will allow users to telnet or ftp > directly from their workstations to the internet without first logging > on the internet machine? Here is a summary of responses I received: Sun Consulting sells a product called IGATEWAY that has both a telnet and an ftp proxy service to do just this. Much better is the free TIS firewall toolkit available by ftp from ftp.tis.com, in directory pub/firewalls/toolkit. You might want to look at that. This will provide firewall service for client systems (ie, your internal systems) of any kind: UNIX or non-UNIX. If your internal systems include UNIX systems then you should also look at the SOCKS package: ftp from ftp.nec.com, in directory /pub/security/socks.cstc. This will give you really seamless use of applications (including things like your Mosaic) through your firewall. Many thanks to the following people: mjr@tis.com Ian Dunkin Walt Sullivan Jeff Welty jerry@tcs.com (Jerry Carlin) Brad.Powell@EBay.Sun.COM ( Brad Powell - Sun CIS) Steve Watt From Firewalls-Owner@GreatCircle.COM Wed Jan 19 16:40:10 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03430; Wed, 19 Jan 94 16:40:10 GMT Received: from esri.com (REDLANDS.ESRI.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03416; Wed, 19 Jan 94 08:39:59 PST Received: from universe ([192.9.155.1]) by esri.com (4.1/SMI-4.1) id AA01772; Wed, 19 Jan 94 08:40:12 PST Received: from arian.universe by universe (4.1/SMI-4.1) id AA04281; Wed, 19 Jan 94 08:38:42 PST Comment: Environmental Systems Research Institute Received: by arian.universe (4.1/SMI-4.1) id AA13454; Wed, 19 Jan 94 08:40:25 PST Date: Wed, 19 Jan 94 08:40:25 PST From: hsafai@esri.com (Houman Safai ) Message-Id: <9401191640.AA13454@arian.universe> To: sun-managers-relay@ra.mcs.anl.gov Subject: Summary:Telnet/Ftp through a firewall Cc: Robert.Bethel@CBIS.Com, firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello Managers, I can always depend on this list. Thanks for all the responses. Most people recommended using the TIS FIrewall Toolkit(fwtk). I have downloaded a copy from the net and will be working on it this week. My original questions was: > I am looking for a product that will allow users to telnet or ftp > directly from their workstations to the internet without first logging > on the internet machine? Here is a summary of responses I received: Sun Consulting sells a product called IGATEWAY that has both a telnet and an ftp proxy service to do just this. Much better is the free TIS firewall toolkit available by ftp from ftp.tis.com, in directory pub/firewalls/toolkit. You might want to look at that. This will provide firewall service for client systems (ie, your internal systems) of any kind: UNIX or non-UNIX. If your internal systems include UNIX systems then you should also look at the SOCKS package: ftp from ftp.nec.com, in directory /pub/security/socks.cstc. This will give you really seamless use of applications (including things like your Mosaic) through your firewall. Many thanks to the following people: mjr@tis.com Ian Dunkin Walt Sullivan Jeff Welty jerry@tcs.com (Jerry Carlin) Brad.Powell@EBay.Sun.COM ( Brad Powell - Sun CIS) Steve Watt From Firewalls-Owner@GreatCircle.COM Wed Jan 19 16:45:51 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03463; Wed, 19 Jan 94 16:45:51 GMT Received: from seas.smu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03456; Wed, 19 Jan 94 08:45:42 PST Received: by seas.smu.edu (/\==/\ Smail3.1.28.1 #28.25) id ; Wed, 19 Jan 94 10:47 CST Received: by seas.smu.edu (/\==/\ Smail3.1.28.1 #28.28 63.63.63.turbo_f) id ; Wed, 19 Jan 94 10:47 CST Message-Id: From: doug@seas.smu.edu (Doug Davis) Subject: Re: double reverse lookup To: Martin_Rex@rz.fht-mannheim.de Date: Wed, 19 Jan 1994 10:47:25 -0600 (CST) Cc: firewalls@GreatCircle.COM In-Reply-To: <199401181426.AA18426@roxi.rz.fht-mannheim.de> from "Martin Rex" at Jan 18, 94 03:26:50 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 731 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > ... Doug Davis wrote: > > > > s=getpeername(sd) /* gets the ip address of the socket */ > > hostname == dns_lookup(s->addr) /* get reverse entry name */ > > ip == dns_gethostip(hostname) /* get forward entry ip address */ > > > > if ip != s->addr reject connection. > > You should be prepared to get more than one address returned when > looking up a hostname, because there are machines that have several > network interfaces, and there are DNS setups which reflect this > (rather than using different hostnames for the same machine, > depending on the referenced interface). > > So you ought to check all addresses that are returned. > Oh thats true, I was just hacking something out to clarify the activity.. From Firewalls-Owner@GreatCircle.COM Wed Jan 19 08:57:33 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03487; Wed, 19 Jan 94 16:49:13 GMT Received: from rome.software.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03480; Wed, 19 Jan 94 08:49:03 PST Received: from venice.software.com [198.17.234.5] by rome.software.com with SMTP id AAA3315; Wed, 19 Jan 1994 08:51:24 -0800 X-Sender: john@rome.software.com X-Mailer: Date: Wed, 19 Jan 1994 08:50:07 -0800 Message-Id: <19940119165124.rome.AAA3315@venice.software.com> To: firewalls@GreatCircle.COM From: John.MacFarlane@Software.com (John L. MacFarlane) (by way of John.MacFarlane@Software.com (John L. MacFarlane)) Subject: Re: dns spoofola Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hobbit wrote: >Suppose someone intent on no good set a packet generator of some sort to firing >lots of DNS replies with the responsible nameserver's source address and >containing spoofed information, both PTR and A, at the target machine? Chances >seem good that the spoof DNS replies would get in there before the real reply >just when the target machine tried to do the lookups, and then access would be >granted to the spoofer's client address... > Unless I am mistaken, DNS puts an ID number in the request/reply. Your packet generator would really have to bombard the target named with bogus requests (which all had different ID #'s) to actually happen on the correct ID for the reply to be used. From Firewalls-Owner@GreatCircle.COM Wed Jan 19 19:43:55 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03992; Wed, 19 Jan 94 19:43:55 GMT Received: from cs.utexas.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03985; Wed, 19 Jan 94 11:43:41 PST Message-Id: <9401191945.AA07887@cs.utexas.edu> Received: from slip-9-2.ots.utexas.edu by cs.utexas.edu (5.64/1.22/mx-relay) with SMTP id AA07887; Wed, 19 Jan 94 13:45:06 -0600 X-Sender: werner@mailbox.cs.utexas.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jan 1994 13:45:49 -0600 To: John Murray From: werner@cs.utexas.edu (Werner Uhrig) Subject: Re: living with reverse DNS lookups Cc: Firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> Separate internal and external DNS servers provide next to nothing in >> terms of increased security. > > Wait a second, from some people I here the argument: > intern/extern DNS is a must for secure sites. > ( otherwise you provide a map of your internal net) > > While others seem to say: > it dosen't matter the info is useless. > (if you take other precautions) > > Opinions? people who do not understand "security by obscurity" and then vigurously argue against it tend to cause this confusion. while putting a sign "Vicious Dog" and leaving the radio, TV and lights on doesn't make it harder to break into your house, it will still have the likely effect that people who cruise your neighbor- hood for an easy target are more likely to "visit" a neighbor. However, the one who had already decided she wants to break into your home faces only slightly increased difficulties... and, as always, there are costs and caveats, and there are additional/better measures worth considering... it's a crap-shoot and one really wants to reduce the likelihood that one ever has to deal with the fall-out of a break-in by discouraging some (amateurs?) from messing with you(r site). p.s.: sorry for the (house) analogy -- please ignore the aspect of it that doesn't apply. From Firewalls-Owner@GreatCircle.COM Wed Jan 19 23:20:59 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04750; Wed, 19 Jan 94 23:20:59 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04743; Wed, 19 Jan 94 15:20:27 PST Message-Id: <9401192320.AA04743@mycroft.GreatCircle.COM> Received: by coombs.anu.edu.au (1.37.109.8/16.2) id AA02264; Thu, 20 Jan 1994 10:23:35 +1100 From: Darren Reed Subject: Re: dns spoofola To: hobbit@wd40.ftp.com (*Hobbit*) Date: Thu, 20 Jan 1994 10:23:33 +1000 (EDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9401181919.AA17785@wd40.ftp.com> from "*Hobbit*" at Jan 18, 94 02:19:17 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 936 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > Lots of packages do inverse and then forward DNS lookup in an attempt to > detect spoofing. A good effort, but ... > > Suppose someone intent on no good set a packet generator of some sort to > firing > lots of DNS replies with the responsible nameserver's source address and > containing spoofed information, both PTR and A, at the target machine? > Chances > seem good that the spoof DNS replies would get in there before the real reply > just when the target machine tried to do the lookups, and then access would be > granted to the spoofer's client address... If it is just a program making a query to its nameserver, then you've also to guess (or otherwise determine) the port number for that program. And once you have that, there are other loops to jump through...such as getting the id right for the DNS query (but most libraries do it sequentially starting at 1 so this shouldn't be hard in most cases >:-/). Darren From Firewalls-Owner@GreatCircle.COM Thu Jan 20 01:30:35 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05099; Thu, 20 Jan 94 01:30:35 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05092; Wed, 19 Jan 94 17:30:26 PST Received: by relay.tis.com; id AA22520; Wed, 19 Jan 94 20:32:08 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma022513; Wed Jan 19 20:32:01 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA05238; Wed, 19 Jan 94 20:31:42 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA03821; Wed, 19 Jan 94 20:31:40 EST Date: Wed, 19 Jan 94 20:31:40 EST From: mjr@tis.com Message-Id: <9401200131.AA03821@otter.tis.com> To: firewalls@GreatCircle.COM, hobbit@wd40.ftp.com Subject: Re: dns spoofola Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Suppose someone intent on no good set a packet generator of some sort to firing >lots of DNS replies with the responsible nameserver's source address and >containing spoofed information, both PTR and A, at the target machine? Chances >seem good that the spoof DNS replies would get in there before the real reply >just when the target machine tried to do the lookups, and then access would be >granted to the spoofer's client address... It's fairly obvious and it's been done. This is one reason we recommend not using DNS-based information for determining how you will deal with a node. I.e., use IP addresses only. IP addresses are doubtless always going to be spoofable too, but as you point out, it's pretty easy to spoof DNS by stuffing a nameserver -- make 'em work for it. IP spoofing takes a higher degree of expertise and access (I believe). mjr. From Firewalls-Owner@GreatCircle.COM Wed Jan 19 20:29:18 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05509; Thu, 20 Jan 94 04:17:33 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05501; Wed, 19 Jan 94 20:17:21 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAvzpp10831; Wed, 19 Jan 94 23:18:35 -0500 Received: from iij.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 211234.15641; Wed, 19 Jan 1994 21:12:34 EST Received: from wincgw1.winc.ad.jp by uucp0.iij.ad.jp (8.6.5+2.3W/2.7W) id LAA09482; Thu, 20 Jan 1994 11:04:46 +0900 Received: by wincgw1.winc.ad.jp (5.67+1.6W/4.18:3.7:winc:931216) id AA01548; Thu, 20 Jan 94 11:05:01 JST Received: from classic.oho.sumikin.co.jp by rice.csd.sumikin.co.jp (4.1/6.4J.6) id AA24030; Thu, 20 Jan 94 10:52:23 JST Received: from tako.oho (oho211) by classic.oho.sumikin.co.jp (4.1/6.4J.6) id AA06611; Thu, 20 Jan 94 10:52:31 JST Message-Id: Date: Thu, 20 Jan 94 10:22:45 PST Reply-To: futoshi@oho.sumikin.co.jp (futoshi miki) From: futoshi@oho.sumikin.co.jp (futoshi miki) To: firewalls@greatcircle.com Subject: Questions about firewall examples Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Sir, If you have some information about the internet firewall applied at Laurence Livermore Lab. or Los Alamos Lab. could you let me know their specifications or what functions they have? We would like to use their firewall systems as reference in case we will connect our internal system with outside world. Any information about firewall examples above is highly appreciated. Thank you for your attention. From Firewalls-Owner@GreatCircle.COM Wed Jan 19 23:04:40 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05765; Thu, 20 Jan 94 06:52:48 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05758; Wed, 19 Jan 94 22:52:38 PST Received: from elf.wang.com by tuna.wang.com with SMTP id AA00945 (5.67a/IDA-1.5 for ); Thu, 20 Jan 1994 01:54:20 -0500 Received: by elf.wang.com id AA29591 (5.67a/IDA-1.5); Thu, 20 Jan 1994 01:54:12 -0500 From: Tom Fitzgerald Message-Id: <199401200654.AA29591@elf.wang.com> Subject: Re: udprelay & archie To: jonl@hal.com (frederick smythe esquire) Date: Thu, 20 Jan 94 1:54:11 EST Cc: firewalls@greatcircle.com In-Reply-To: <9401180550.AA15467@gorn.hal.com>; from "frederick smythe, esquire" at Jan 17, 94 9:50 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > i'm trying to toss udprelay up and use archie/xarchie > as a client to verify it works. the udprelay seems to > be listening just fine, and the client seems to be sending > to the right place, yet the relayer doesn't seem to be > noticing it. If you run udprelay with -d2, it will print to stdout a detailed log of what it decides to do with each packet. You should see something like this (for the initial outbound UDP request which starts up the session): pkt rcvd from addr=150.124.8.2, port=1179, pktlen=169 De-encapsulating validate (assoc=0x4058a8, addr=150.124.8.2/port=1179) Validated ok .... some stuff skipped .... opensocket assoc=0x405110, localport=0 opensocket: localport bound to port 4618 opened socket 7 for assoc 0x405110 .... some stuff skipped .... packet sent to assoc=0x405110 socket=7 addr=128.6.18.15 port=1525 .... (In this case, 128.6.18.15 is archie.rutgers.edu). If it doesn't say "Validated ok" then it doesn't think your client is authorized to send through the firewall - there's something wrong with the left-hand side of the appropriate line in /etc/udprelay.conf. If it really does send the packet, perhaps it's going to the wrong place? If something *really* went wrong, something should have been written to your syslog. If you post (or mail me) your udprelay.conf and a -d2 output, I'll take a look. -- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA From Firewalls-Owner@GreatCircle.COM Thu Jan 20 07:22:39 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05852; Thu, 20 Jan 94 07:22:39 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05845; Wed, 19 Jan 94 23:22:29 PST Received: from elf.wang.com by tuna.wang.com with SMTP id AA01449 (5.67a/IDA-1.5 for ); Thu, 20 Jan 1994 02:24:08 -0500 Received: by elf.wang.com id AA00688 (5.67a/IDA-1.5); Thu, 20 Jan 1994 02:24:03 -0500 From: Tom Fitzgerald Message-Id: <199401200724.AA00688@elf.wang.com> Subject: Re: double reverse lookup To: netmaine@ansremote.com (Andrew T. Robinson) Date: Thu, 20 Jan 94 2:24:01 EST Cc: firewalls@greatcircle.com In-Reply-To: <199401181414.AA11435@p-o.ans.net>; from "Andrew T. Robinson" at Jan 18, 94 8:53 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > If I understand everything I've read, split-universe DNS doesn't seem to be > worth the trouble: > > * Potential loss of access to services which rely on double-reverse lookups If you don't really have a firewall, this is true. Every system that is IP-reachable from the outside should be listed in the DNS map you present to the outside. You can have a split universe with fake names in the external map, but if someone can get a system to respond to even the most basic connection attempt, they can probably find out everything you were trying to hide in the DNS. So it's hardly worth it. > On the other hand, the idea of split DNS is intuitively attractive to me for > a reason entirely separate from security: since you are only advertising > one or a few hosts (instead of hundreds or thousands) which are accessible > to the public Internet, it's easier for people to access services you may > choose to provide. > Right now I would (have in fact) advise omitting split DNS from a firewall > setup, with the qualification that some/most of the foremost security > experts on the Internet recommend it. I'm certainly no expert... but for people with opaque firewalls (i.e. IP connectivity to only a few systems, with application gateways for all services provided across the firewall), split DNS can be worthwhile. I've actually just recently started thinking this, and there are postings from me in the past arguing that split DNS is a waste of effort even for firewalled sites. With split DNS: - The external map can list only the MX records which really are visible from the outside, so outsiders don't have to go through the list of hidden MXs, timing out, until they finally locate your external mail relay. - Your external map will probably be MUCH smaller, and won't change nearly as often as the internal map. This is a nice thing to do for your off- site secondaries. - You can use a wildcard MX, which lets mail be relayed to internal systems the moment the system is set up, instead of waiting for the zone transfers to occur to all the secondaries which need to know about it. (I have mixed feelings about this one - if you make a tiny mistake and the wildcard MX infects the internal DNS, you're in deep trouble.) - The external map can list only the specific interfaces on multihomed hosts which are reachable from outside. This eliminates more timeouts/retries. - As Andy says, the external map can contain things that you -want- people to notice: TXT records with contact information, obvious aliases for ftp, archie or gopher (or the lack of those aliases), or whatever. It's not buried in 1000s of lines of A records and repetitive MX records. My domain uses a single DNS map, but I plan on splitting it as soon as it becomes possible. But I do think that the external map should list every system that can be the source or destination of an IP packet to/from the outside. -- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA From Firewalls-Owner@GreatCircle.COM Thu Jan 20 07:58:18 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05949; Thu, 20 Jan 94 07:58:18 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05942; Wed, 19 Jan 94 23:58:03 PST Received: from elf.wang.com by tuna.wang.com with SMTP id AA01902 (5.67a/IDA-1.5 for ); Thu, 20 Jan 1994 02:59:45 -0500 Received: by elf.wang.com id AA01838 (5.67a/IDA-1.5); Thu, 20 Jan 1994 02:59:38 -0500 From: Tom Fitzgerald Message-Id: <199401200759.AA01838@elf.wang.com> Subject: Re: living with reverse DNS lookups To: werner@cs.utexas.edu (Werner Uhrig) Date: Thu, 20 Jan 94 2:59:36 EST Cc: John.Murray@germany.eu.net, Firewalls@greatcircle.com In-Reply-To: <9401191945.AA07887@cs.utexas.edu>; from "Werner Uhrig" at Jan 19, 94 1:45 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > while putting a sign "Vicious Dog" and leaving the radio, TV and > lights on doesn't make it harder to break into your house, it will > still have the likely effect that people who cruise your neighbor- > hood for an easy target are more likely to "visit" a neighbor. I've never really liked this argument, since it does nothing to improve security or reduce the number of attackers, it's just a way of getting the attackers to break into somebody else's site. If we all do this, then we've done nothing useful: we've wasted a lot of time and still have the same number of attackers to worry about. (Or more likely, if most of us do what you recommend, then the last few schmucks are in big trouble.) I'd like to keep my site secure, but not by getting someone else broken into. -- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA From Firewalls-Owner@GreatCircle.COM Thu Jan 20 03:05:31 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06275; Thu, 20 Jan 94 09:52:02 GMT Received: from tadpole.tadpole.com (Tadpole.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06268; Thu, 20 Jan 94 01:51:53 PST Received: by tadpole.tadpole.com (4.1/SMI-4.1-jim) id AA03582; Thu, 20 Jan 94 03:53:15 CST Date: Thu, 20 Jan 94 03:53:15 CST From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9401200953.AA03582@tadpole.tadpole.com> To: hsafai@esri.com, svu@esri.com Subject: Re: Summary:Telnet/Ftp through a firewall Cc: Robert.Bethel@CBIS.Com, firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Um, given that I wrote what became IGATEWAY, I'd use socks. Jim From Firewalls-Owner@GreatCircle.COM Thu Jan 20 13:24:13 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06929; Thu, 20 Jan 94 13:24:13 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06922; Thu, 20 Jan 94 05:24:05 PST Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA03138 for ; Thu, 20 Jan 94 08:20:17 -0500 Received: from lorax.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA24633; Thu, 20 Jan 94 08:16:18 EST Received: from localhost by lorax.imsi.com (4.1/SMI-4.1) id AA06206; Thu, 20 Jan 94 08:16:17 EST Message-Id: <9401201316.AA06206@lorax.imsi.com> To: firewalls@greatcircle.com Subject: Active Defense Reply-To: rens@imsi.com Date: Thu, 20 Jan 1994 08:16:17 -0500 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi- What do people think of the notion of 'active defense'? For instance, upon detecting an attack from a given host or net, an active defense might automatically shut down the attacker with ICMP host unreachables, send mail to root at his site, and perhaps tell the border router to filter all packets from that address. Obviously you'd have to be careful with the implementation not to go overboard, shutting down huge sites, legitimate users, etc. It's more the general idea that I'd like critiqued. -Rens From Firewalls-Owner@GreatCircle.COM Thu Jan 20 13:33:14 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07013; Thu, 20 Jan 94 13:33:14 GMT Received: from MCIGATEWAY.MCIMail.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07005; Thu, 20 Jan 94 05:32:55 PST Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ac16966; 20 Jan 94 13:12 GMT Date: Thu, 20 Jan 94 08:15 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: firewalls Subject: DNS blocking question Message-Id: <43940120131534/0003858921NA3EM@mcimail.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have been toying with the following setup for a firewall. It is based on the TIS architecture of a screened subnet with bastion hosts... I am using a split DNS. The private network has a stub for the public network: root, com with MX and other records as needed. The public network has a stub for the private network: gateways, MX etc. There are at least two bastion hosts. HOST 1: Is Primary public DNS (a handful of records), anon FTP, public gopher, etc. It has no TELNETD or others, all maint is done from the Console (via a reverse TELNET server on the private side of the segment). I am considering doing a shared SCSI with a system on the private side of the segment to put data safely on this box. Don't know how feasable that is. Let us call this host -- info.corp.com HOST 2: Mail hub, TELNET and FTP proxy etc. This system needs both DNSs. To do this it would cache the public DNS from HOST 1 and secondary corp.com from th private DNS. Thus, being authoritative for corp.com, it would properly resolve all internal names and will resolve all public names from the public DNS. Initial tests seem to show that this will work. A request is being written for enough hardware to fully test this out. Let us call this host -- relay.corp.com QUESTION 1: Does anyone have this DNS setup? Does it work or are there flaws? QUESTION 2: It seems that a public person can NSLOOKUP relay.corp.com and SET TYPE=ls and get the whole internal network. DiG might also do the trick. How might relay.corp.com's Name Server be set up not to honour any public net requests for DNS info? BTW, one interesting argument against publishing your internal DNS (particulary if you have HINFO records) is to make it harder for vendors to know how many of their and competitor systems you really have. Bob Moskowitz From Firewalls-Owner@GreatCircle.COM Thu Jan 20 06:54:42 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07174; Thu, 20 Jan 94 14:46:59 GMT Received: from p-o.ans.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07154; Thu, 20 Jan 94 06:46:47 PST Received: by p-o.ans.net id AA11274 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Thu, 20 Jan 1994 09:41:52 -0500 Message-Id: <199401201441.AA11274@p-o.ans.net> Date: Thu, 20 Jan 94 09:27:22 EST From: "Andrew T. Robinson" To: firewalls@greatcircle.com Subject: Questions about firewall examples Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From: futoshi@oho.sumikin.co.jp (futoshi miki) >If you have some information about the internet firewall applied at Laurence >Livermore Lab. or >Los Alamos Lab. could you let me know their specifications or what functions >they have? >We would like to use their firewall systems as reference in case we will >connect our internal system with outside world. > >Any information about firewall examples above is highly appreciated. >Thank you for your attention. Am I just becoming paranoid or is this social engineering in action? :-) Andy From Firewalls-Owner@GreatCircle.COM Thu Jan 20 07:04:43 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07172; Thu, 20 Jan 94 14:46:59 GMT Received: from p-o.ans.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07155; Thu, 20 Jan 94 06:46:47 PST Received: by p-o.ans.net id AA11278 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Thu, 20 Jan 1994 09:41:56 -0500 Message-Id: <199401201441.AA11278@p-o.ans.net> Date: Thu, 20 Jan 94 09:31:03 EST From: "Andrew T. Robinson" To: firewalls@greatcircle.com Cc: juballa@nlbbs.com Subject: Re: living with reverse DNS lookups Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I've never really liked this argument, since it does nothing to improve >security or reduce the number of attackers, Well, not only that but an Internet connection is not a house. Even if you want to use that metaphor, then split-universe DNS isn't like putting signs and barking dogs on the premises--it's more like putting a big tarp over the house with a sign out front that says "NO HOUSE HERE." There are admittedly some pretty stupid burglars out there, but there are still a lot (burglars and non-burglars alike) who will be curious enough to take a peek under the tarp (THEN they get mauled by the trained tigers, lying in ambush, who might strike at any moment). If your firewall relies on IP addresses as everyone seems to recommend, and if your router is set up to deny packets appearing to come from your network over the serial (Internet) interface, how do IP and DNS spoofing on the *Internet* remain a threat?? I'm making the hazardous assumption that the site is secure and all your users are good... I back that assumption up with a pointy stick and for extreme cases a Glock 17. Andy From Firewalls-Owner@GreatCircle.COM Thu Jan 20 16:39:07 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07557; Thu, 20 Jan 94 16:39:07 GMT Received: from elroy.jpl.nasa.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07546; Thu, 20 Jan 94 08:38:58 PST Received: from puente.Jpl.Nasa.Gov by elroy.jpl.nasa.gov (4.1/SMI-4.1+DXR) id AA05816; Thu, 20 Jan 94 08:40:29 PST Received: from triton.JPL.NASA.GOV by puente.Jpl.Nasa.Gov (4.1/SMI-4.1+DXRs2.0) id AA17344; Thu, 20 Jan 94 08:43:41 PST Date: Thu, 20 Jan 94 08:43:41 PST From: robert@puente.jpl.nasa.gov (Robert Angelino) Message-Id: <9401201643.AA17344@puente.Jpl.Nasa.Gov> To: firewalls@greatcircle.com Subject: Re: Summary:Telnet/Ftp through a firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Is there a FAQ for this newsgroup??? If not, there should be... -robert From Firewalls-Owner@GreatCircle.COM Thu Jan 20 16:44:54 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07577; Thu, 20 Jan 94 16:44:54 GMT Received: from transfer.stratus.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07569; Thu, 20 Jan 94 08:44:35 PST Received: from swdc.stratus.com (stratus.swdc.stratus.com [134.111.20.37]) by transfer.stratus.com (8.6.4/8.6.4) with SMTP id LAA27766; Thu, 20 Jan 1994 11:46:17 -0500 Received: by swdc.stratus.com (4.1/SMI-4.1.10) id AA02572; Thu, 20 Jan 94 08:41:36 PST Date: Thu, 20 Jan 94 08:41:36 PST Message-Id: <9401201641.AA02572@swdc.stratus.com> From: aegl@stratus.swdc.stratus.com To: rens@imsi.com, firewalls@GreatCircle.COM Subject: Re: Active Defense Content-Length: 1338 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Rens Troost wrote: > What do people think of the notion of 'active defense'? For instance, > upon detecting an attack from a given host or net, an active defense > might automatically shut down the attacker with ICMP host unreachables, > send mail to root at his site, and perhaps tell the border router to > filter all packets from that address. I'm not sure that I like having the "border routers" so easily reprogrammable ... unless you get it right it leaves you open to yet another type of attack (where the bad guy first gets you to 'lower you shields'). I'd like to have the routers config burnt in PROM ... but failing that only allow reconfiguration from a console in a (physically) secure location. Sending mail to root may result in an automatic mailwar (if the bad guy finds two sites with this kind of automatic defense ... then launches an attack on each one that appears to have come from the other). You'd also want to be pretty sure of your facts before having a system send accusing mail out. - Tony "The problem, of course, was that even though the information was coming a lot faster, the vast majority of it, having originated with human beings, was still wrong. Eventually people realized that the Information Superhighway was essentially CB radio, but with more typing." -- Dave Barry From Firewalls-Owner@GreatCircle.COM Thu Jan 20 16:58:55 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07612; Thu, 20 Jan 94 16:58:55 GMT Received: from thor.tjhsst.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07605; Thu, 20 Jan 94 08:58:34 PST Received: by thor.tjhsst.edu (Smail3.1.28.1 #1) id m0pN2je-000DNYC; Thu, 20 Jan 94 11:59 EST Message-Id: To: hsafai@esri.com (Houman Safai ) Cc: firewalls@greatcircle.com Subject: Re: Summary:Telnet/Ftp through a firewall In-Reply-To: Your message of "Wed, 19 Jan 1994 08:40:51 EST." <9401191640.AA13457@arian.universe> Date: Thu, 20 Jan 1994 11:59:56 EST From: Craig Metz Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9401191640.AA13457@arian.universe>, you write: >Much better is the free TIS firewall toolkit available by ftp from >ftp.tis.com, in directory pub/firewalls/toolkit. You might want to look >at that. This will provide firewall service for client systems (ie, your >internal systems) of any kind: UNIX or non-UNIX. I notice that there is no ftp.tis.com:/pub/firewalls... -Craig From Firewalls-Owner@GreatCircle.COM Thu Jan 20 18:09:13 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07875; Thu, 20 Jan 94 18:09:13 GMT Received: from isi.com (hopper.isi.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07868; Thu, 20 Jan 94 10:09:06 PST Received: from chief.isi.com by isi.com (4.1/Ultrix3.0-C) id AA11671; Thu, 20 Jan 94 10:11:46 PST Received: by chief.isi.com (4.1/inc/isi-1.6s) id AA18284; Thu, 20 Jan 94 10:13:37 PST Date: Thu, 20 Jan 94 10:13:37 PST From: langston@isi.com (Richard Langston x247) Message-Id: <9401201813.AA18284@chief.isi.com> To: firewalls@GreatCircle.COM, rens@imsi.com Subject: Re: Active Defense Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >What do people think of the notion of 'active defense'? For instance, >upon detecting an attack from a given host or net, an active defense >might... Hey, that sounds like Tek War! Let's all put on our virtual reality suits and join the Matrix Police!! From Firewalls-Owner@GreatCircle.COM Thu Jan 20 10:27:25 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07850; Thu, 20 Jan 94 18:03:31 GMT Received: from MCIGATEWAY.MCIMail.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07842; Thu, 20 Jan 94 10:03:21 PST Received: from mcimail.com by MCIGATEWAY.MCIMail.com id bk00514; 20 Jan 94 16:25 GMT Date: Thu, 20 Jan 94 11:24 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: firewalls Subject: Has anyone heard of the following setup? Message-Id: <24940120162442/0003858921NA3EM@mcimail.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A dualed home host firewall uses a security access card. The firewall has a TELNETD and TELNET and FTP clients. The firewall has static routes to specific internal hosts. The internal users must first TELNET to the firewall from an authorized internal host and use their security card for the login. >From there, the user must TELNET to a 'trusted' public host IP filtering on the router only allows port 25 from/to anywhere. >From the 'trusted' public host the user can TELNET or FTP to public sites. If FTP is used to get a file, the user must then log off the trusted public file and get the file from there to the firewall. From the firewall, the user can put the file on the internal authorized host... Draconian at least. The QUESTION is: Is there any valid security reason for the 'trusted' public host. I should note that for many internal users, their 'trusted' public host is a popular local university host with LOTS of users from all over.... Bob From Firewalls-Owner@GreatCircle.COM Thu Jan 20 10:29:07 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07857; Thu, 20 Jan 94 18:03:37 GMT Received: from isi.com (hopper.isi.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07843; Thu, 20 Jan 94 10:03:28 PST Received: from chief.isi.com by isi.com (4.1/Ultrix3.0-C) id AA11653; Thu, 20 Jan 94 10:06:17 PST Received: by chief.isi.com (4.1/inc/isi-1.6s) id AA18200; Thu, 20 Jan 94 10:08:07 PST Date: Thu, 20 Jan 94 10:08:07 PST From: langston@isi.com (Richard Langston x247) Message-Id: <9401201808.AA18200@chief.isi.com> To: firewalls@GreatCircle.COM, netmaine@ansremote.com Subject: Re: living with reverse DNS lookups Cc: juballa@nlbbs.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Well, not only that but an Internet connection is not a house. Even if you want >to use that metaphor, then split-universe DNS isn't like putting signs and >barking dogs on the premises--it's more like putting a big tarp over the house >with a sign out front that says "NO HOUSE HERE." There are admittedly some I'd have to agree with this! I don't really understand the fuss about giving out your hostnames. If I were trying to crack your site, I'd do it by scanning IP ranges, not looking to see what your hostnames are. IMHO, the only people who are hurt by none issuing reverse-lookup info are your users, who want to use ftp or other services. And putting out false names- why? The only legitimate reason I can think of is if you have your hostnames the same as your users, and you don't want anyone to figure out the names of your employees. That's why I don't give out any of my system aliases. I"ve had a site I administered invaded, but I'm still not as paranoid as lots of folks who hangout here :-) From Firewalls-Owner@GreatCircle.COM Thu Jan 20 18:58:19 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08159; Thu, 20 Jan 94 18:58:19 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08144; Thu, 20 Jan 94 10:57:35 PST Message-Id: <9401201857.AA08144@mycroft.GreatCircle.COM> To: "Andrew T. Robinson" Cc: firewalls@greatcircle.com Subject: Re: Questions about firewall examples In-Reply-To: Your message of Thu, 20 Jan 94 09:27:22 EST Date: Thu, 20 Jan 1994 10:57:34 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Andrew T. Robinson" writes: # From: futoshi@oho.sumikin.co.jp (futoshi miki) # >If you have some information about the internet firewall applied at Laurence # # >Livermore Lab. or # >Los Alamos Lab. could you let me know their specifications or what functions # # >they have? # >We would like to use their firewall systems as reference in case we will # >connect our internal system with outside world. # > # >Any information about firewall examples above is highly appreciated. # >Thank you for your attention. # # Am I just becoming paranoid or is this social engineering in action? :-) # # Andy The folks who built and maintian the Lawrence Livermore National Lab firewall read this list. I'm sure they saw the query. How they choose to follow up is their business; I don't see any reason why the mailing list should devote any further attention to the issue. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Thu Jan 20 19:14:58 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08330; Thu, 20 Jan 94 19:14:58 GMT Received: from muse.microunity.com (muse1.microunity.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08323; Thu, 20 Jan 94 11:14:49 PST Received: from gaea.microunity.com by muse.microunity.com (4.1/ericm1.1) id AA09056; Thu, 20 Jan 94 11:16:09 PST Received: from angst.microunity.com by gaea.microunity.com (4.1/muse1.3) id AA22558; Thu, 20 Jan 94 11:16:13 PST Received: by angst.microunity.com (5.61/muse.mw-2) id AA13416; Thu, 20 Jan 94 11:16:09 -0800 From: ericm@MicroUnity.com (Eric Murray) Message-Id: <9401201916.AA13416@angst.microunity.com> Subject: Re: Active Defense To: rens@imsi.com Date: Thu, 20 Jan 94 11:16:07 PST Cc: firewalls@GreatCircle.COM In-Reply-To: <9401201316.AA06206@lorax.imsi.com>; from "Rens Troost" at Jan 20, 94 8:16 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Rens Troost wrote: > > > Hi- > > What do people think of the notion of 'active defense'? For instance, > upon detecting an attack from a given host or net, an active defense > might automatically shut down the attacker with ICMP host unreachables, A really bad idea. You (or I) don't have the right to shut down another site that way, no matter what they might have done. It also sets a bad precedent of active hostility instead of cooperation between site admins. Turned the other way 'round, if say one of my users was trying to break into your system, and rather than notify me you hosed my site via ICMP host unreachables (or whatever), I'd feel less than inclined to help you out by tracking down the offending user. > send mail to root at his site Not so bad an idea. Still, your program would have to be quite well-written to avoid false messages or (as another poster explained) being explioted by the 'bad guys' to indirectly harass someone. Also, automatic mail is more likely to be ignored than "real" mail... > and perhaps tell the border router to > filter all packets from that address. Fine, though there's potential security loopholes. > Obviously you'd have to be careful with the implementation not to go > overboard, shutting down huge sites, legitimate users, etc. It's more > the general idea that I'd like critiqued. Generally I feel I have the right to filter whatever packets I receive, but don't have the right to filter what another site puts out or to shut them down. -- ericm ericm@microunity.com From Firewalls-Owner@GreatCircle.COM Thu Jan 20 12:13:01 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08541; Thu, 20 Jan 94 19:52:33 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08534; Thu, 20 Jan 94 11:52:22 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id LAA26969 for ; Thu, 20 Jan 1994 11:54:05 -0800 Message-Id: <199401201954.LAA26969@mailgate.cadence.com> Received: from unknown(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id sma026945; Thu Jan 20 11:53:38 1994 Date: Thu, 20 Jan 1994 11:53:38 -0800 To: firewalls@greatcircle.com From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Modem scanner Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We were probed yesterday by someone looking for dialout modems. They tried to telnet to all of our annex terminal servers (which are all handily called (annexsomething) and gatorlink boxes. I wouldn't normally bother to mention this other than the significant time period between each telnet attempt, as if the hacker was going through a very long list, like maybe everything with "annex" or "gator" in its name in the universe. The probes came from sugar-bombs.gnu.ai.mit.edu 128.52.46.18. This is some kind of public access system I think, and they are not interested in following this up. I am curious, did any other firewalls folk log this kind of activity? It happened to us between 14:36 PST Wednesday and 03:09 PST Thursday. annex tip: These boxes listen on ports 5000-50nn where nn is the number of device ports it has. If you have them at your site, beware. The hacker went for port 23 so doesn't know much about annexes or firewalls. Al --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From Firewalls-Owner@GreatCircle.COM Thu Jan 20 13:47:39 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08938; Thu, 20 Jan 94 21:40:29 GMT Received: from uu3.psi.com ([38.145.250.2]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08929; Thu, 20 Jan 94 13:40:20 PST Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA07669 for ; Thu, 20 Jan 94 16:20:41 -0500 Received: from lorax.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA26716; Thu, 20 Jan 94 16:11:49 EST Received: from localhost by lorax.imsi.com (4.1/SMI-4.1) id AA17093; Thu, 20 Jan 94 16:11:48 EST Message-Id: <9401202111.AA17093@lorax.imsi.com> To: aegl@stratus.swdc.stratus.com Cc: rens@imsi.com, firewalls@greatcircle.com Subject: Re: Active Defense In-Reply-To: Your message of "Thu, 20 Jan 1994 08:41:36 PST." <9401201641.AA02572@swdc.stratus.com> Reply-To: rens@imsi.com Date: Thu, 20 Jan 1994 16:11:48 -0500 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Thu, 20 Jan 94 08:41:36 PST, aegl@stratus.swdc.stratus.com said: aegl> I'm not sure that I like having the "border routers" so easily aegl> reprogrammable ... unless you get it right it leaves you open aegl> to yet another type of attack (where the bad guy first gets aegl> you to 'lower you shields'). I'd like to have the routers aegl> config burnt in PROM ... but failing that only allow aegl> reconfiguration from a console in a (physically) secure aegl> location. I suppose SNMPv2 might provide adequate security, but I use a different approach. The router console is wired to a terminal server poort on the internal subnet. A daemon process is attached to the console, and accepts (authenticated) commands to do modifications. There's also a passthrough, for actual console access via telnet. This has the advantage that it can also capture router console status messages, which might otherwise go unheeded. aegl> Sending mail to root may result in an automatic mailwar (if aegl> the bad guy finds two sites with this kind of automatic aegl> defense ... then launches an attack on each one that appears Good point. -Rens From Firewalls-Owner@GreatCircle.COM Thu Jan 20 16:13:03 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09709; Fri, 21 Jan 94 00:07:54 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09702; Thu, 20 Jan 94 16:07:44 PST Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA28464 for ; Thu, 20 Jan 94 18:51:13 -0500 Received: from lorax.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA27767; Thu, 20 Jan 94 18:39:02 EST Received: from localhost by lorax.imsi.com (4.1/SMI-4.1) id AA29829; Thu, 20 Jan 94 18:39:01 EST Message-Id: <9401202339.AA29829@lorax.imsi.com> To: ericm@microunity.com (Eric Murray) Cc: rens@imsi.com, firewalls@greatcircle.com Subject: Re: Active Defense In-Reply-To: Your message of "Thu, 20 Jan 1994 11:16:07 PST." <9401201916.AA13416@angst.microunity.com> Reply-To: rens@imsi.com Date: Thu, 20 Jan 1994 18:39:01 -0500 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Thu, 20 Jan 94 11:16:07 PST, ericm@MicroUnity.com (Eric Murray) said: ericm> A really bad idea. You (or I) don't have the right to shut ericm> down another site that way, no matter what they might have ericm> done. It also sets a bad precedent of active hostility ericm> instead of cooperation between site admins. Just sending unreachables for your firewall/network will only shut down routing to you. It's active, but not, I deem, offensive. intelligence would have to be used in applying these methods, of course. -Rens From Firewalls-Owner@GreatCircle.COM Thu Jan 20 16:33:08 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09806; Fri, 21 Jan 94 00:26:40 GMT Received: from muse.microunity.com (muse1.microunity.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09799; Thu, 20 Jan 94 16:26:33 PST Received: from gaea.microunity.com by muse.microunity.com (4.1/ericm1.1) id AA11131; Thu, 20 Jan 94 16:28:16 PST Received: from angst.microunity.com by gaea.microunity.com (4.1/muse1.3) id AA08027; Thu, 20 Jan 94 16:28:19 PST Received: by angst.microunity.com (5.61/muse.mw-2) id AA14507; Thu, 20 Jan 94 16:28:15 -0800 From: ericm@MicroUnity.com (Eric Murray) Message-Id: <9401210028.AA14507@angst.microunity.com> Subject: Re: Active Defense To: rens@imsi.com Date: Thu, 20 Jan 94 16:28:13 PST Cc: ericm@MicroUnity.com, firewalls@greatcircle.com In-Reply-To: <9401202339.AA29829@lorax.imsi.com>; from "Rens Troost" at Jan 20, 94 6:39 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Rens Troost wrote: > > > >>>>> On Thu, 20 Jan 94 11:16:07 PST, ericm@MicroUnity.com (Eric Murray) said: > > ericm> A really bad idea. You (or I) don't have the right to shut > ericm> down another site that way, no matter what they might have > ericm> done. It also sets a bad precedent of active hostility > ericm> instead of cooperation between site admins. > > Just sending unreachables for your firewall/network will only shut > down routing to you. It's active, but not, I deem, offensive. Ah. I read your message as sending unreachables for _them_. Isn't that a common denial-of-service attack? -- ericm ericm@microunity.com From Firewalls-Owner@GreatCircle.COM Thu Jan 20 16:34:43 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09794; Fri, 21 Jan 94 00:25:21 GMT Received: from thor.tjhsst.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09786; Thu, 20 Jan 94 16:25:12 PST Received: by thor.tjhsst.edu (Smail3.1.28.1 #1) id m0pN9iE-000DNiC; Thu, 20 Jan 94 19:26 EST Message-Id: To: firewalls@greatcircle.com Subject: Implementing ``good'' firewall router code Date: Thu, 20 Jan 1994 19:26:53 EST From: Craig Metz Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I am going to be doing some patches to Linux's networking system to support interface filtering as a way to firewall. One question of opinion I have for people with more implementation experience has to do with decoding vs. the use of masks. I had planned to do something like basically starting with a table for IP filtering that basically holds a number of 40-byte records. Each would be a 20-byte mask, a 20-byte value, and a comparison-inversion flag. The result of the filter would then be the binary AND of the mask with the basic IP 20-byte header compared to the value. For instance, if one wanted to drop IP packets with a protocol of 42, they would invoke a user program that sent to the kernel a mask with all of the fields but the protocol set to 0, the byte corresponding to the protocol field set to 0xff, a mask with all zeros but the protocol field set to 42, and a set inversion flag (to make all packets that satisfy this rule *not* ok). Similar things would be done to TCP and UDP headers. The other option would be to use a data structure and do an operation like this on specific fields, individually. This would be much more computationally expensive in most situations than the above method. My question, then, would be to those who have implemented filtering. What kind of a general method at the low levels did you use, and what do you think about/ for/against this method of filtering? It seems to me like it would be *extremely* easy to implement, since most of the real work is done in a kernel- interface program to set up the masks. The memory space is not a big concern unless you have giant tables, but bit-masks may allow one to do fun things there, too. If anyone has thoughts on this, please let me know. -Craig From Firewalls-Owner@GreatCircle.COM Fri Jan 21 00:36:27 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09873; Fri, 21 Jan 94 00:36:27 GMT Received: from rome.software.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09866; Thu, 20 Jan 94 16:36:15 PST Received: from venice.software.com [198.17.234.5] by rome.software.com with SMTP id AAA11457; Thu, 20 Jan 1994 16:38:25 -0800 X-Sender: john@rome.software.com X-Mailer: Date: Thu, 20 Jan 1994 16:37:00 -0800 Message-Id: <19940121003825.rome.AAA11457@venice.software.com> To: firewalls@GreatCircle.COM From: John.MacFarlane@Software.com (John L. MacFarlane) Subject: Re: Does BIND-4.9 use ID word? (fwd) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > >I was just wondering if BIND ver. 4.9(.2) uses the ID word to match >a query to a reply or is the ID field for the reply ignored? > >My motivation for the question: Can someone force-feed a bogus answer >to a resolver or named query sent to an external nameserver. It seems to >me that a bogus answer would need the correct 16bit ID field of the query >to be accepted (depending on how BIND uses this ID). > > Indeed, BIND does compare the ID field to match responses to queries. > Forcefeeding a bogus answer isn't easy. It has been made even > more difficult with the VALIDATE patch in BIND 4.9.2. Wait for > the public release and read accompanying notes to figure out > how to use it. > > -anant > John L. MacFarlane (John.MacFarlane@Software.com) Software.com 6487A Calle Real (805) 967-5022 Santa Barbara, California 93117 (805) 964-4507 Fax. From Firewalls-Owner@GreatCircle.COM Fri Jan 21 06:20:36 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10858; Fri, 21 Jan 94 06:20:36 GMT Received: from nsco.network.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10851; Thu, 20 Jan 94 22:20:27 PST Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA23978; Fri, 21 Jan 94 00:25:27 -0600 Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA23474; Fri, 21 Jan 94 00:20:46 CST Date: Fri, 21 Jan 94 00:20:46 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9401210620.AA23474@anubis.network.com> To: firewalls@GreatCircle.COM Subject: Re: Active Defense Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >The router console is wired to a terminal server >poort on the internal subnet. I guess that a) the answer to my previous question is 'yes' and that b) if I'd read the original item more closely I would have known that. Y'all just excuse me while I creep sheepishly back out, ok? Andrew From Firewalls-Owner@GreatCircle.COM Fri Jan 21 07:14:01 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10989; Fri, 21 Jan 94 07:14:01 GMT Received: from shadow.net (anshar.shadow.net) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10982; Thu, 20 Jan 94 23:13:52 PST Received: from localhost (jc@localhost) by shadow.net (8.6.4/jc-1.0) id CAA26221; Fri, 21 Jan 1994 02:16:38 -0500 Date: Fri, 21 Jan 1994 02:05:47 -0500 (EST) From: Justin Subject: Re: Modem scanner To: Alastair Young Cc: firewalls@GreatCircle.COM In-Reply-To: <199401201954.LAA26969@mailgate.cadence.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Thu, 20 Jan 1994, Alastair Young wrote: > annex tip: These boxes listen on ports 5000-50nn where nn is the number of > device ports it has. If you have them at your site, beware. The hacker went > for port 23 so doesn't know much about annexes or firewalls. If the ports are set to CLI mode, this isn't a problem, but if they are in adaptive or slave mode, remote users can connect to 5000-50xx and 7000-70xx as well. Also make sure that VCLI security is enabled. -jc From Firewalls-Owner@GreatCircle.COM Fri Jan 21 09:24:42 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11492; Fri, 21 Jan 94 09:24:42 GMT Received: from checkpoint.brm.co.il (doors.brm.co.il) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11485; Fri, 21 Jan 94 01:24:18 PST Received: from monk.UUCP by checkpoint.brm.co.il (4.1/SMI-4.0) id AA02007; Fri, 21 Jan 94 11:28:20 IST Received: by checkpoint.brm.co.il (4.1/SMI-4.1) id AA00726; Fri, 21 Jan 94 11:23:46 IST Date: Fri, 21 Jan 94 11:23:46 IST From: gil@checkpoint.brm.co.il (Gil Shwed) Message-Id: <9401210923.AA00726@checkpoint.brm.co.il> To: tbrink@crl.com, firewalls@greatcircle.com Subject: Re: Pings... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: Tom Brink > > My firewall is fairly simple. I simply placed a filter on my Wellfleet > router that blocks all IP packets for port 0-24,26-1024, leaving port > 25 open (SMTP) for my mail. What is odd is that one can 'ping' my > 'protected' subnet from outside the firewall. Am I missing > something here? What port does ping use? > -- > Tom Brink > Technical Support Specialist > Computer Aided Engineering Section > Arizona Department of Transportation > 205 S. 17th Avenue, 622E > Phoenix, AZ 85007 Ping uses ICMP with an ICMP_ECHO request, Allowing ping will only allow harrasments from the net to your host. However, for proper network performance, you need to allow most ICMP requests. Moreover, in the design you quoted, you are leaving all ports >1024 open, which leaves your system exposed and *vulnerable* to dangerours attacks: 1. Cracking your yellow pages (NIS) databases. (RPC/UDP) 2. Fetching Files (NFS) 3. X11 attacks. 4. Many other open services. Current crackers techniques (and automated tools) explore all the above mentioned security holes. Take care. -- Gil Shwed -- CheckPoint Software Technologies From Firewalls-Owner@GreatCircle.COM Fri Jan 21 02:55:56 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11898; Fri, 21 Jan 94 10:41:21 GMT Received: from mailhost.visionware.co.uk (vision.visionware.co.uk) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11891; Fri, 21 Jan 94 02:41:08 PST Received: by mailhost.visionware.co.uk (5.59/5.930520) id AA14591; Fri, 21 Jan 94 10:33:52 GMT Newsgroups: vw.net.firewalls Path: chrisd From: chrisd@visionware.co.uk (Chris Davies) Subject: Re: Pings... Message-Id: <1994Jan21.103329.14547@visionware.co.uk> Organization: VisionWare Ltd., Leeds, UK X-Newsreader: TIN [version 1.2 PL1] References: <9401210923.AA00726.vw.net.firewalls@checkpoint.brm.co.il> Date: Fri, 21 Jan 1994 10:33:29 GMT Apparently-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Gil Shwed (gil@checkpoint.brm.co.il) wrote: : > router that blocks all IP packets for port 0-24,26-1024, leaving port : Moreover, in the design you quoted, you are leaving all ports >1024 open, : which leaves your system exposed and *vulnerable* to dangerours attacks: : 1. Cracking your yellow pages (NIS) databases. (RPC/UDP) : 2. Fetching Files (NFS) : 3. X11 attacks. : 4. Many other open services. Er, point (3) is fair enough (ports 6000-60nn and 7000) but why (1) and (2)? I thought that these RPC based services had to go via the portmapper (port 111)? Or is it that the actual services are on anonymous ports up in the >1024 range and that a port scanner could find them (eventually)? Chris -- VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England Tel +44 532 788858. Fax +44 532 304676. Email chrisd@visionware.co.uk -------- "VisionWare: The home of DOS/SQL/UNIX/X/VMS integration" -------- From Firewalls-Owner@GreatCircle.COM Fri Jan 21 11:44:04 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12049; Fri, 21 Jan 94 11:44:04 GMT Received: from mail.fwi.uva.nl by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12042; Fri, 21 Jan 94 03:43:43 PST Received: from adam.fwi.uva.nl by mail.fwi.uva.nl with SMTP (5.65c/5.1) id AA01408; Fri, 21 Jan 1994 12:45:24 +0100 Received: by adam.fwi.uva.nl from localhost.fwi.uva.nl with SMTP (5.65c(FWI)/2.0) id AA03723; Fri, 21 Jan 1994 12:44:27 +0100 Message-Id: <199401211144.AA03723@adam.fwi.uva.nl> X-Organisation: Faculty of Mathematics & Computer Science University of Amsterdam Kruislaan 403 NL-1098 SJ Amsterdam The Netherlands X-Phone: +31 20 525 7463 X-Telex: 10262 hef nl X-Fax: +31 20 525 7490 To: chrisd@visionware.co.uk (Chris Davies) Cc: firewalls@greatcircle.com Subject: Re: Pings... In-Reply-To: Your message of "Fri, 21 Jan 94 10:33:29 GMT." <1994Jan21.103329.14547@visionware.co.uk> Date: Fri, 21 Jan 94 12:44:26 +0100 From: Casper Dik Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Gil Shwed (gil@checkpoint.brm.co.il) wrote: >: > router that blocks all IP packets for port 0-24,26-1024, leaving port > >: Moreover, in the design you quoted, you are leaving all ports >1024 open, >: which leaves your system exposed and *vulnerable* to dangerours attacks: >: 1. Cracking your yellow pages (NIS) databases. (RPC/UDP) >: 2. Fetching Files (NFS) >: 3. X11 attacks. >: 4. Many other open services. > >Er, point (3) is fair enough (ports 6000-60nn and 7000) but why (1) and >(2)? I thought that these RPC based services had to go via the >portmapper (port 111)? Or is it that the actual services are on >anonymous ports up in the >1024 range and that a port scanner could >find them (eventually)? You don't need the portmapper for RPC. All you have to do is probe the range of ports where you expect a certain service to be. Modern NIS/YP implementations will bind to ports < 1024, mainly to tell the portmapper ``root owns this service'', a fact which the portmapper uses to prevent mere mortals from starting their own ypserv. BTW, ypserv is RPC/UDP and RPC/TCP. NFS always uses #2049/udp. I don't think that the portmapper is queried for this. Older NFS implementations didn't even bother to tell the portmapper they were present (SunOS 3.x) Since the insecure nature of NFS, filtering any traffic to 2049/udp is highly recommended. Casper From Firewalls-Owner@GreatCircle.COM Fri Jan 21 12:05:22 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12099; Fri, 21 Jan 94 12:05:22 GMT Received: from checkpoint.brm.co.il (doors.brm.co.il) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12092; Fri, 21 Jan 94 04:05:09 PST Received: from monk.UUCP by checkpoint.brm.co.il (4.1/SMI-4.0) id AA02156; Fri, 21 Jan 94 14:08:37 IST Received: by checkpoint.brm.co.il (4.1/SMI-4.1) id AA02162; Fri, 21 Jan 94 14:03:42 IST Date: Fri, 21 Jan 94 14:03:42 IST From: gil@checkpoint.brm.co.il (Gil Shwed) Message-Id: <9401211203.AA02162@checkpoint.brm.co.il> To: chrisd@visionware.co.uk, firewalls@greatcircle.com Subject: Re: Pings... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Chris Davies wrote: > > Gil Shwed (gil@checkpoint.brm.co.il) wrote: > : > router that blocks all IP packets for port 0-24,26-1024, leaving port > > : Moreover, in the design you quoted, you are leaving all ports >1024 open, > : which leaves your system exposed and *vulnerable* to dangerours attacks: > : 1. Cracking your yellow pages (NIS) databases. (RPC/UDP) > : 2. Fetching Files (NFS) > : 3. X11 attacks. > : 4. Many other open services. > > Er, point (3) is fair enough (ports 6000-60nn and 7000) but why (1) and > (2)? I thought that these RPC based services had to go via the > portmapper (port 111)? Or is it that the actual services are on > anonymous ports up in the >1024 range and that a port scanner could > find them (eventually)? > (1) RPC services are on anonymous ports (they are *not* pre-determined), the portmapper (sunrpc, port 111) is used only for the program-number -> port-number mapping. Scanning is very easy since RPC services usually find themselves on ports just over 1023. RPC/YP scanners like these were used by Internet intruders, and had very successfull results... (2) Though NFS is RPC service, it uses port 2049 on standard systems. (4) Many services also use >1023 ports. Recent Internet attacks showed torjan horses getting through other holes (SMTP), waiting for root shells from the net... -- Gil Shwed -- CheckPoint Software Technologies From Firewalls-Owner@GreatCircle.COM Fri Jan 21 12:47:23 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12243; Fri, 21 Jan 94 12:47:23 GMT Received: from checkpoint.brm.co.il (doors.brm.co.il) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12236; Fri, 21 Jan 94 04:47:03 PST Received: from monk.UUCP by checkpoint.brm.co.il (4.1/SMI-4.0) id AA02253; Fri, 21 Jan 94 14:50:45 IST Received: by checkpoint.brm.co.il (4.1/SMI-4.1) id AA02379; Fri, 21 Jan 94 14:41:44 IST Date: Fri, 21 Jan 94 14:41:44 IST From: gil@checkpoint.brm.co.il (Gil Shwed) Message-Id: <9401211241.AA02379@checkpoint.brm.co.il> To: chrisd@visionware.co.uk, casper@fwi.uva.nl Subject: Re: Pings... Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Casper Dik wrote: > Modern NIS/YP implementations will bind to ports < 1024, mainly > to tell the portmapper ``root owns this service'', a fact which > the portmapper uses to prevent mere mortals from starting their > own ypserv. BTW, ypserv is RPC/UDP and RPC/TCP. > Note that ypbind remains >1023, letting anybody fetch your NIS databases. -- Gil Shwed -- CheckPoint Software Technologies From Firewalls-Owner@GreatCircle.COM Fri Jan 21 12:52:04 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12273; Fri, 21 Jan 94 12:52:04 GMT Received: from mail.fwi.uva.nl by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12266; Fri, 21 Jan 94 04:51:50 PST Received: from adam.fwi.uva.nl by mail.fwi.uva.nl with SMTP (5.65c/5.1) id AA02539; Fri, 21 Jan 1994 13:53:28 +0100 Received: by adam.fwi.uva.nl from localhost.fwi.uva.nl with SMTP (5.65c(FWI)/2.0) id AA04335; Fri, 21 Jan 1994 13:52:04 +0100 Message-Id: <199401211252.AA04335@adam.fwi.uva.nl> X-Organisation: Faculty of Mathematics & Computer Science University of Amsterdam Kruislaan 403 NL-1098 SJ Amsterdam The Netherlands X-Phone: +31 20 525 7463 X-Telex: 10262 hef nl X-Fax: +31 20 525 7490 To: gil@checkpoint.brm.co.il (Gil Shwed) Cc: chrisd@visionware.co.uk, firewalls@GreatCircle.COM Subject: Re: Pings... In-Reply-To: Your message of "Fri, 21 Jan 94 14:41:44 +0700." <9401211241.AA02379@checkpoint.brm.co.il> Date: Fri, 21 Jan 94 13:52:03 +0100 From: Casper Dik Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Casper Dik wrote: >> Modern NIS/YP implementations will bind to ports < 1024, mainly >> to tell the portmapper ``root owns this service'', a fact which >> the portmapper uses to prevent mere mortals from starting their >> own ypserv. BTW, ypserv is RPC/UDP and RPC/TCP. >> >Note that ypbind remains >1023, letting anybody fetch your NIS >databases. You cannot fetch YP databases through ypbind. Ypbind will only tell you which ypserv it is using (host.prot). If you run ypbind -s (on Suns, possibly others) it will bind to a reserved port. Again this will stop ypbind from being reregistered (enough to become root once you're on a host) and will also force ypbind to bind to a ypserv registered on a reserved port, also a slight increase in security. Casper From Firewalls-Owner@GreatCircle.COM Fri Jan 21 14:28:21 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12511; Fri, 21 Jan 94 14:28:21 GMT Received: from BGUVM.BGU.AC.IL by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12500; Fri, 21 Jan 94 06:28:10 PST Received: from ramon.bgu.ac.il by BGUVM.BGU.AC.IL (IBM VM SMTP V2R2) with TCP; Fri, 21 Jan 94 16:30:01 IST Received: by ramon.bgu.ac.il (920330.SGI/920502.SGI.AUTO) for @bguvm.bgu.ac.il:firewalls@greatcircle.com id AA25964; Fri, 21 Jan 94 16:25:46 +0200 From: jsz@ramon.bgu.ac.il Message-Id: <9401211425.AA25964@ramon.bgu.ac.il> Subject: Re: Pings... To: gil@checkpoint.brm.co.il (Gil Shwed), firewalls@greatcircle.com Date: Fri, 21 Jan 94 16:25:38 IST In-Reply-To: <9401210923.AA00726@checkpoint.brm.co.il>; from "Gil Shwed" at Jan 21, 94 11:23 am Origanization: The Society for the Propagation of Healthy Sex & Prevention of Pervertness X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Ping uses ICMP with an ICMP_ECHO request, > Allowing ping will only allow harrasments from the net to your host. > However, for proper network performance, you need to allow most ICMP requests. I do not think that ICMP_ECHO request could be annoying, however, ICMP_UNREACHABLE requests can be used to make a host drop connections, which is quite annoying indeed, but there is a Patch-ID# 100567-04, it's not too good, but then again, it's better than nothing. > Moreover, in the design you quoted, you are leaving all ports >1024 open, > which leaves your system exposed and *vulnerable* to dangerours attacks: > 1. Cracking your yellow pages (NIS) databases. (RPC/UDP) > 2. Fetching Files (NFS) > 3. X11 attacks. > 4. Many other open services. > Current crackers techniques (and automated tools) explore all the above > mentioned security holes. Take care. And MANY MANY others vulnerabilities. Will Sun Inc. ever release a patch for syslogd vulnerability? --- Jonathan From Firewalls-Owner@GreatCircle.COM Fri Jan 21 14:42:58 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12564; Fri, 21 Jan 94 14:42:58 GMT Received: from BGUVM.BGU.AC.IL by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12557; Fri, 21 Jan 94 06:42:40 PST Received: from ramon.bgu.ac.il by BGUVM.BGU.AC.IL (IBM VM SMTP V2R2) with TCP; Fri, 21 Jan 94 16:44:50 IST Received: by ramon.bgu.ac.il (920330.SGI/920502.SGI.AUTO) for @bguvm.bgu.ac.il:firewalls@greatcircle.com id AA26133; Fri, 21 Jan 94 16:40:45 +0200 From: jsz@ramon.bgu.ac.il Message-Id: <9401211440.AA26133@ramon.bgu.ac.il> Subject: Re: Pings... To: casper@fwi.uva.nl (Casper Dik), firewalls@greatcircle.com Date: Fri, 21 Jan 94 16:40:37 IST In-Reply-To: <199401211144.AA03723@adam.fwi.uva.nl>; from "Casper Dik" at Jan 21, 94 12:44 pm Origanization: The Society for the Propagation of Healthy Sex & Prevention of Pervertness X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > You don't need the portmapper for RPC. All you have to do is > probe the range of ports where you expect a certain service to > be. > > Modern NIS/YP implementations will bind to ports < 1024, mainly > to tell the portmapper ``root owns this service'', a fact which > the portmapper uses to prevent mere mortals from starting their > own ypserv. BTW, ypserv is RPC/UDP and RPC/TCP. > > NFS always uses #2049/udp. I don't think that the portmapper > is queried for this. Older NFS implementations didn't even bother > to tell the portmapper they were present (SunOS 3.x) > > Since the insecure nature of NFS, filtering any traffic to 2049/udp > is highly recommended. > Filtering traffic to 2049, and udp at all is necessary, but alas, the cisco routers that we have got here have no means of forwarding all rejected packets to a specified machine, and as far as I am aware cisco routers do not provide any good logging performance, hence no possible way to see who is knocking on your door, and etc. Somewhat I like Wietse Venema's replacement of portmapper. At least you can see if anyone tried to ypsnarf your NIS-maps, to guess the NFS file handles, and etc. Enough said.. --- Jonathan From Firewalls-Owner@GreatCircle.COM Fri Jan 21 16:08:54 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12741; Fri, 21 Jan 94 16:08:54 GMT Received: from mail.fwi.uva.nl by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12734; Fri, 21 Jan 94 08:08:32 PST Received: from adam.fwi.uva.nl by mail.fwi.uva.nl with SMTP (5.65c/5.1) id AA05817; Fri, 21 Jan 1994 17:09:47 +0100 Received: by adam.fwi.uva.nl from localhost.fwi.uva.nl with SMTP (5.65c(FWI)/2.0) id AA05520; Fri, 21 Jan 1994 17:09:33 +0100 Message-Id: <199401211609.AA05520@adam.fwi.uva.nl> X-Organisation: Faculty of Mathematics & Computer Science University of Amsterdam Kruislaan 403 NL-1098 SJ Amsterdam The Netherlands X-Phone: +31 20 525 7463 X-Telex: 10262 hef nl X-Fax: +31 20 525 7490 To: jsz@ramon.bgu.ac.il Cc: firewalls@GreatCircle.COM Subject: Re: Pings... In-Reply-To: Your message of "Fri, 21 Jan 94 16:25:38 +0700." <9401211425.AA25964@ramon.bgu.ac.il> Date: Fri, 21 Jan 94 17:09:32 +0100 From: Casper Dik Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >And MANY MANY others vulnerabilities. Will Sun Inc. ever release a patch for >syslogd vulnerability? All programs that use information from /etc/utmp have been fixed in Solaris 2.3. This includes syslogd, walld, comsat etc. Some of those may have been fixed in SunOS 4.1.3_U1. Casper From Firewalls-Owner@GreatCircle.COM Fri Jan 21 16:58:58 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12819; Fri, 21 Jan 94 16:58:58 GMT Received: from scubed.scubed.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12812; Fri, 21 Jan 94 08:58:46 PST Received: by scubed.scubed.com (5.57/scubed3.1) id AA20268; Fri, 21 Jan 94 09:00:19 PST Received: from localhost by s3sol.scubed.com (8.6.4/S-CUBED-C-1) id JAA28950; Fri, 21 Jan 1994 09:00:17 -0800 Date: Fri, 21 Jan 1994 09:00:17 -0800 From: schneide@scubed.scubed.com (Steve Schneider) Message-Id: <199401211700.JAA28950@s3sol.scubed.com> To: firewalls@greatcircle.com Subject: Re: Modem scanner Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Alastair Young (alastiar@cadence.com) wrote: > We were probed yesterday by someone looking for dialout modems. They tried > to telnet to all of our annex terminal servers (which are all handily > called (annexsomething) and gatorlink boxes. I wouldn't normally bother to > mention this other than the significant time period between each telnet > attempt, as if the hacker was going through a very long list, like maybe > everything with "annex" or "gator" in its name in the universe. The probes > came from sugar-bombs.gnu.ai.mit.edu 128.52.46.18. This is some kind of > public access system I think, and they are not interested in following this > up. > > I am curious, did any other firewalls folk log this kind of activity? It > happened to us between 14:36 PST Wednesday and 03:09 PST Thursday. > We one of our Annex terminal servers was also probed from this same address at 0728, 0729, and 2303 PST. None of our other five Annex terminal servers were probed. Steve From Firewalls-Owner@GreatCircle.COM Fri Jan 21 17:14:15 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12886; Fri, 21 Jan 94 17:14:15 GMT Received: from babyoil.ftp.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12879; Fri, 21 Jan 94 09:14:08 PST Received: by babyoil.ftp.com id AA23360; Fri, 21 Jan 94 12:15:58 -0500 Date: Fri, 21 Jan 94 12:15:58 -0500 From: hobbit@babyoil.ftp.com (*Hobbit*) Message-Id: <9401211715.AA23360@babyoil.ftp.com> To: firewalls@greatcircle.com Subject: portmap Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Wietse's hacked portmap is a cool idea, but it hasn't been ported to all that many platforms. I've given it a try or two but I'm not all that RPC-literate. Is there any other porting effort in the works, particularly in the direction of SV compliance? Some observed problems off the top of my head: HPUX tends to spin off a zillion duplicate portmap processes as requests come in. Solaris has "rpcbind" or something, which apparently isn't the same. OSF/1 tends to not send any responses to the caller, even though things like pmap_set *do* get through and have effect. It won't even *build* on an AIX box, due to missing .h files. Another thing that would be great and wonderful would be a "mountd" replacement, with code to fix all the stupid bugs like hard-limited netgroup and export list size. I realize that all of the above is effectively a formality, because once one is armed with a file handle and a path to port 2049, it's all over... _H* From Firewalls-Owner@GreatCircle.COM Fri Jan 21 17:30:20 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13008; Fri, 21 Jan 94 17:30:20 GMT Received: from netcomsv.netcom.com (uucp6.netcom.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12997; Fri, 21 Jan 94 09:30:06 PST Received: from harker.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id JAA23750; Fri, 21 Jan 1994 09:26:22 -0800 Received: from science.harker.com (science.harker.com) by harker.com (4.1/simpleuucp1.0a) id AA19415; Fri, 21 Jan 94 08:24:29 PST Date: Fri, 21 Jan 94 08:24:29 PST From: harker@harker.com (Robert Harker) Message-Id: <9401211624.AA19415@harker.com> To: alastair@cadence.com, firewalls@GreatCircle.COM Subject: Re: Modem scanner & living with reverse DNS lookups Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > To: firewalls@GreatCircle.COM > From: alastair@cadence.com (Alastair Young) > Subject: Modem scanner > > We were probed yesterday by someone looking for dialout modems. They tried > to telnet to all of our annex terminal servers (which are all handily ^^^^^^^^^^^^^^^^^^^^^ > called (annexsomething) and gatorlink boxes. I wouldn't normally bother to ^^^^^^^^^^^^^^^^^^^^^^^ I also recommend split DNS domain with limited information to the outside and a private internal DNS domain with private internal information. I recommend this for exactly the above reason. If Cadence (or site XYZ) had not been advertizing their hostnames, they would have been less likely to be attacked by this person. I do not think this is security through obscurity. I think it is a common sense security precaution to limit the amount of information a site makes available to the outside world anonymously. In my opinion, a common factor in many attacks is the use of publically available information to either find a host to attack, words to use in the attack, or to use in convincing an internal person to release inside information to an outside person. Why make it easy for an attacker to obtain this information by advertizing it through DNS, why not make the attacker work a little for the information. Hope this helps RLH Robert Harker sendmail and TCP/IP Network Training Harker Systems Network and Sysadmin Consulting harker@harker.com 1180 Hester Ave netcom!harker!harker San Jose, CA 95126 uunet!harker!harker 408-295-9432 From Firewalls-Owner@GreatCircle.COM Fri Jan 21 09:34:52 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12990; Fri, 21 Jan 94 17:28:15 GMT Received: from knock.aa.ans.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12980; Fri, 21 Jan 94 09:28:08 PST Received: by knock.aa.ans.net id AA99976 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Fri, 21 Jan 1994 12:29:54 -0500 From: "Vatsal P. Sonecha" Message-Id: <199401211729.AA99976@knock.aa.ans.net> Subject: Please add me to this list. To: firewalls@greatcircle.com Date: Fri, 21 Jan 1994 12:29:54 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 204 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, I work for Advanced Network & Services, Inc. at their Network Operations Center in Ann Arbor. I am the security point of contact here and so am intereseted in getting this mailing. Thanks, Vatsal. From Firewalls-Owner@GreatCircle.COM Fri Jan 21 17:40:45 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13049; Fri, 21 Jan 94 17:40:45 GMT Received: from eagle.is.lmsc.lockheed.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13042; Fri, 21 Jan 94 09:40:33 PST Received: from zuni.litc.lockheed.com by eagle.is.lmsc.lockheed.com (5.65/Ultrix4.3-C) id AA10073; Fri, 21 Jan 1994 09:41:24 -0800 Received: by zuni.litc.lockheed.com (5.64/10.1) id AA02723; Fri, 21 Jan 94 09:41:54 -0800 Date: Fri, 21 Jan 94 09:41:54 -0800 From: edwardsg@zuni.litc.lockheed.com (Gregory W. Edwards) Message-Id: <9401211741.AA02723@zuni.litc.lockheed.com> To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Good morning; I am interested in the relationship between Internet throughput, firewall security, and services allowed. If possible, could you answer the questions below: 1. What bandwidth do you support for your external Internet connection? Do you gather utilization statistics and do you have anything to share? Example, what type of traffic, size of files, length of response time for different services, etc. 2. What hardware, software and security controls do you use to provide an external firewall to the Internet or other external connections? 3. What type of services/protocols do you enable across the firewall? Which directions? Can you discuss your issues and concerns? 4. Do you have a firewall policy that you can summarize or share? 5. What problems have you encountered either from intrusion, administration, performance, etc? 6. Do you plan to expand service, protocols and functionality as demands increase? 7. Do you enable direct communications through the firewall from workstations, PCs, Macs, etc? What type of monitoring and audit do you do? 8. Do you use an SMTP gateway or filtering server? 9. Any other restrictions, concerns, please share.. 10. What field is your company (aerospace, banking, etc.)? 11. How many computers/workstations/PCs/Macs are served? 12. How many active Internet users and what are they using? Please send responses to: edwardsg@zuni.litc.lockheed.com. If enough people request results, I will post them back to the maillist. Thank you. Greg Edwards From Firewalls-Owner@GreatCircle.COM Fri Jan 21 09:41:31 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12940; Fri, 21 Jan 94 17:25:02 GMT Received: from nawc690.chinalake.navy.mil (nawc690a.nwc.navy.mil) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12924; Fri, 21 Jan 94 09:24:50 PST Received: from localhost (mcclung@localhost) by nawc690.chinalake.navy.mil (8.6.4/8.6.4.2-CL) id JAA01755; Fri, 21 Jan 1994 09:23:21 -0800 From: Scott McClung Message-Id: <199401211723.JAA01755@nawc690.chinalake.navy.mil> Subject: Re: Pings... To: casper@fwi.uva.nl (Casper Dik) Date: Fri, 21 Jan 1994 09:23:21 -0800 (PST) Cc: firewalls@GreatCircle.COM In-Reply-To: <199401211609.AA05520@adam.fwi.uva.nl> from "Casper Dik" at Jan 21, 94 05:09:32 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 569 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Casper Dik: > >And MANY MANY others vulnerabilities. Will Sun Inc. ever release a patch for > >syslogd vulnerability? Don't hold your breath. > All programs that use information from /etc/utmp have been fixed > in Solaris 2.3. This includes syslogd, walld, comsat etc. > Some of those may have been fixed in SunOS 4.1.3_U1. According to the release notes for 4.1.3_U1, there isn't a patch for this. (Assuming you mean bug ID 1133861: syslog can be used to overwrite any system file.) -- Scott McClung Computer Engineer, SAIC mcclung@nawc690.chinalake.navy.mil From Firewalls-Owner@GreatCircle.COM Fri Jan 21 09:44:52 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12967; Fri, 21 Jan 94 17:27:31 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12960; Fri, 21 Jan 94 09:27:21 PST Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA06499; Fri, 21 Jan 94 12:20:39 -0500 Received: by cobalt.house.gov (AA00901); Fri, 21 Jan 94 12:25:41 -0800 Date: Fri, 21 Jan 94 12:25:41 -0800 From: Dorian Deane Message-Id: <9401212025.AA00901@cobalt.house.gov> To: alastair@cadence.com, firewalls@GreatCircle.COM Subject: Re: Modem scanner (and split DNS) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In light of the recent thread on the utility of split DNS, I thought this was particularly interesting: > From: alastair@cadence.com (Alastair Young) > > We were probed yesterday by someone looking for dialout modems. They tried > to telnet to all of our annex terminal servers (which are all handily > called (annexsomething) and gatorlink boxes. I wouldn't normally bother to > mention this other than the significant time period between each telnet > attempt, as if the hacker was going through a very long list, like maybe > everything with "annex" or "gator" in its name in the universe. The probes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You could, of course, rail against such informative names, but personally I think this is a point in favor of split DNS, particularly if name service is not managed by the people who do security. The career debater might also point out that split DNS is security by obscurity, but so is blocking finger service, yet most of us (I think) do that. dorian From Firewalls-Owner@GreatCircle.COM Fri Jan 21 10:01:31 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13104; Fri, 21 Jan 94 17:55:07 GMT Received: from tadpole.tadpole.com (Tadpole.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13094; Fri, 21 Jan 94 09:54:55 PST Received: by tadpole.tadpole.com (4.1/SMI-4.1-jim) id AA16157; Fri, 21 Jan 94 11:56:41 CST Date: Fri, 21 Jan 94 11:56:41 CST From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9401211756.AA16157@tadpole.tadpole.com> To: harker@harker.com Subject: Re: Modem scanner & living with reverse DNS lookups Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I hate to tell you this, but its trivial to write a program to run through a segment of the IP address space, looking for ports that are 'active'. Such a program can even gain a fair amount of parallism by using as many descriptors (e.g. sockets) as the system will let it have. (For instance, SunOS 4.1.X will let you use up to 256 file descriptors per process, you'll need one for output to some file, other process, ...). Hiding your names does *nothing*, other than alert someone that you have something to hide. Jim From Firewalls-Owner@GreatCircle.COM Fri Jan 21 10:04:53 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13093; Fri, 21 Jan 94 17:54:34 GMT Received: from sps.lane.edu (godzilla.sps.lane.edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13086; Fri, 21 Jan 94 09:54:25 PST Received: from adm.sps.lane.edu by sps.lane.edu (5.0/SMI-SVR4) id AA01608; Fri, 21 Jan 94 09:55:14 PST Received: from ccMail by adm.sps.lane.edu id AA759175126 Fri, 21 Jan 94 09:58:46 pdt Date: Fri, 21 Jan 94 09:58:46 pdt From: gshepher@adm.sps.lane.edu Encoding: 645 Text Message-Id: <9400217591.AA759175126@adm.sps.lane.edu> To: firewalls@GreatCircle.COM Subject: Re[2]: Pings... Content-Length: 631 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> From: Tom Brink >> >> My firewall is fairly simple. I simply placed a filter on my Wellfleet >> router that blocks all IP packets for port 0-24,26-1024, leaving port >> 25 open (SMTP) for my mail. What is odd is that one can 'ping' my >> 'protected' subnet from outside the firewall. Am I missing >> something here? What port does ping use? Isn't simpler to just allow necessary ports, rather thatn trying to guess and filter all vulnerable ports? Being new here, what does everyone consider necessary ports for Internet access? Our users telnet, ftp, gopher, and mail straight out over the net. From Firewalls-Owner@GreatCircle.COM Fri Jan 21 10:11:33 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13114; Fri, 21 Jan 94 17:57:31 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13106; Fri, 21 Jan 94 09:57:20 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id JAA08079 for ; Fri, 21 Jan 1994 09:59:02 -0800 Message-Id: <199401211759.JAA08079@mailgate.cadence.com> Received: from unknown(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id sma007996; Fri Jan 21 09:58:46 1994 Date: Fri, 21 Jan 1994 09:58:45 -0800 To: firewalls@greatcircle.com From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: Modem scanner (and split DNS) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >In light of the recent thread on the utility of split DNS, I thought >this was particularly interesting: > >> From: alastair@cadence.com (Alastair Young) >> >> We were probed yesterday by someone looking for dialout modems. They tried >> to telnet to all of our annex terminal servers (which are all handily >> called (annexsomething) and gatorlink boxes. I wouldn't normally bother to >> mention this other than the significant time period between each telnet >> attempt, as if the hacker was going through a very long list, like maybe >> everything with "annex" or "gator" in its name in the universe. The probes > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >You could, of course, rail against such informative names, but >personally I think this is a point in favor of split DNS, particularly >if name service is not managed by the people who do security. > >The career debater might also point out that split DNS is security >by obscurity, but so is blocking finger service, yet most of us (I >think) do that. > >dorian We do actually use split DNS, but only to present different MX data to the outside world and to protect our internal DNS servers from gross spoofing. We do not shield our hostnames. We tried it once but then our users couldn't access all of those security concious reverse lookup ftp servers. We could put out bogus info, but I think that is a bad trend. I find DNS lookup information from other sites to be very useful sometimes, and I think it is "impolite" not to return the favour. I believe in security by security. This probe did not get past our firewall and was never any threat to us. I got the impression from the time spread between the alphabetically ordered probes that we were a small part of a big list. I am just curious to find out if this theory is correct. If it is then some hacker is going to have lots of fun running up someone else's phone bill. On the other hand, there is no reason not to make the buggers work for their access failures. This is probably a FAQ but how do you restrict who can do zone transfers? Is it possible to persuade network vendors to restrict zone transfers from the secondary they are running for us? (page reference in O'Reilly DNS + BIND is enough. I can't find it) Al --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From Firewalls-Owner@GreatCircle.COM Fri Jan 21 10:41:33 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13373; Fri, 21 Jan 94 18:33:45 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13352; Fri, 21 Jan 94 10:33:24 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id KAA09919 for ; Fri, 21 Jan 1994 10:35:08 -0800 Message-Id: <199401211835.KAA09919@mailgate.cadence.com> Received: from unknown(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id smab09828; Fri Jan 21 10:34:03 1994 Date: Fri, 21 Jan 1994 10:34:03 -0800 To: firewalls@greatcircle.com From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: Modem scanner Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > >We one of our Annex terminal servers was also probed from this same >address at 0728, 0729, and 2303 PST. None of our other five Annex terminal >servers were probed. > >Steve Bingo! Some firewalless site is going to get a very big phone bill next quarter. Are all of your annexes called "annexNNNNN"? Al --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From Firewalls-Owner@GreatCircle.COM Fri Jan 21 10:51:33 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13442; Fri, 21 Jan 94 18:41:13 GMT Received: from rodan.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13432; Fri, 21 Jan 94 10:41:02 PST Received: by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AAvzvm29849; Fri, 21 Jan 94 13:42:37 -0500 Message-Id: <9401211842.AAvzvm29849@rodan.UU.NET> To: jim@Tadpole.COM (Jim Thompson) Cc: harker@harker.com, firewalls@greatcircle.com Subject: Re: Modem scanner & living with reverse DNS lookups In-Reply-To: Your message of "Fri, 21 Jan 1994 11:56:41 CST." <9401211756.AA16157@tadpole.tadpole.com> Date: Fri, 21 Jan 1994 13:42:36 -0500 From: "Louis A. Mamakos" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I hate to tell you this, but its trivial to write a program to > run through a segment of the IP address space, looking for ports > that are 'active'. And if you're trying to find a particular flavor box, you can just send SNMP queries for system.sysObjectID... You don't need names to figure out what the box is in many cases. louie From Firewalls-Owner@GreatCircle.COM Fri Jan 21 10:54:53 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13456; Fri, 21 Jan 94 18:43:14 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13448; Fri, 21 Jan 94 10:42:55 PST Message-Id: <9401211842.AA13448@mycroft.GreatCircle.COM> To: chrisd@visionware.co.uk (Chris Davies) Cc: Firewalls@GreatCircle.COM Subject: Re: Pings... In-Reply-To: Your message of Fri, 21 Jan 1994 10:33:29 GMT Date: Fri, 21 Jan 1994 10:42:53 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk chrisd@visionware.co.uk (Chris Davies) writes: # Gil Shwed (gil@checkpoint.brm.co.il) wrote: # : > router that blocks all IP packets for port 0-24,26-1024, leaving port # # : Moreover, in the design you quoted, you are leaving all ports >1024 open, # : which leaves your system exposed and *vulnerable* to dangerours attacks: # : 1. Cracking your yellow pages (NIS) databases. (RPC/UDP) # : 2. Fetching Files (NFS) # : 3. X11 attacks. # : 4. Many other open services. # # Er, point (3) is fair enough (ports 6000-60nn and 7000) but why (1) and # (2)? I thought that these RPC based services had to go via the # portmapper (port 111)? Or is it that the actual services are on # anonymous ports up in the >1024 range and that a port scanner could # find them (eventually)? The latter, "eventually" being on the order of minutes or even seconds. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Fri Jan 21 19:08:01 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13712; Fri, 21 Jan 94 19:08:01 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13703; Fri, 21 Jan 94 11:07:53 PST Message-Id: <9401211907.AA13703@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: Modem scanner & living with reverse DNS lookups Date: Fri, 21 Jan 1994 11:07:52 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I think both sides of the "hide internal DNS info" versus "don't hide internal DNS info" have been well presented here, but the debate is now showing signs of turning into another flame war. At this point, let's just agree to disagree, and leave it at that. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Fri Jan 21 19:45:22 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14090; Fri, 21 Jan 94 19:45:22 GMT Received: from transfer.stratus.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14075; Fri, 21 Jan 94 11:45:10 PST Received: from swdc.stratus.com (stratus.swdc.stratus.com [134.111.20.37]) by transfer.stratus.com (8.6.4/8.6.4) with SMTP id OAA06901 for ; Fri, 21 Jan 1994 14:46:51 -0500 Received: by swdc.stratus.com (4.1/SMI-4.1.10) id AA16648; Fri, 21 Jan 94 11:46:50 PST Date: Fri, 21 Jan 94 11:46:50 PST Message-Id: <9401211946.AA16648@swdc.stratus.com> From: aegl@stratus.swdc.stratus.com To: firewalls@GreatCircle.COM Subject: Re: Modem scanner (and split DNS) Content-Length: 889 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > On the other hand, there is no reason not to make the buggers work for > their access failures. This is probably a FAQ but how do you restrict who > can do zone transfers? Is it possible to persuade network vendors to > restrict zone transfers from the secondary they are running for us? (page > reference in O'Reilly DNS + BIND is enough. I can't find it) Don't zone transfers come in as TCP connections to port 53, while regular lookups are UDP port 53. This makes it easy (if you have a filtering router between your DNS server and the rest of the world) to only allow zone transfers to your secondaries. I guess you'd just have to ask your secondaries not to allow zone transfers. This is just a delaying tactic though ... as an attacker can ask for PTR records for every possible address on your net(s) (which doesn't take long if you only have a bunch of class-C nets). -Tony From Firewalls-Owner@GreatCircle.COM Fri Jan 21 19:59:37 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14266; Fri, 21 Jan 94 19:59:37 GMT Received: from rand.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14259; Fri, 21 Jan 94 11:59:28 PST Received: from moose.rand.org by rand.org with SMTP id AA28394 (5.67a/IDA-1.5 for ); Fri, 21 Jan 1994 12:01:11 -0800 Received: from boris.rand.org by moose.rand.org; Fri, 21 Jan 94 12:01:10 PST Received: from localhost by boris.rand.org (4.1/SMI-4.1) id AA01126; Fri, 21 Jan 94 12:01:08 PST Message-Id: <9401212001.AA01126@boris.rand.org> To: firewalls@greatcircle.com Subject: Re: Modem scanner Date: Fri, 21 Jan 94 12:01:06 PST From: Robert Schwartzkopf Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Alastair Young (alastiar@cadence.com) wrote: > I am curious, did any other firewalls folk log this kind of activity? It > happened to us between 14:36 PST Wednesday and 03:09 PST Thursday. Our annexes were all probed as well, starting about 12:00 PST Wednesday through 02:00 Thursday. Bob Schwartzkopf From Firewalls-Owner@GreatCircle.COM Fri Jan 21 12:21:35 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14437; Fri, 21 Jan 94 20:08:24 GMT Received: from vaxb.acs.uwlax.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14430; Fri, 21 Jan 94 12:08:11 PST Received: from VMSmail by vaxb.acs.uwlax.edu; Fri, 21 Jan 94 14:09 CDT Message-Id: <24012114093810@vaxb.acs.uwlax.edu> Date: Fri, 21 Jan 94 14:09 CDT From: "Michael Nittmann, The Trane Company?" Subject: modem probe To: firewalls@greatcircle.com X-Vms-To: IN%"firewalls@greatcircle.com" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, I tried to identify the address and could not link it to gnu.ai.mit.edu. Looks to me as if the hacker had previously probed the gnu server and then grabbed one of its ports to go further. I would encourage everybody to always publish here 'suspect' addresses. I blanked the gnu net out since they seem not to be inclined to check for that event (see earlier message on this). Just to add: not only Xterminals, but also X software for PCs (in my case ncd's) has configuration ports. The installation default is -- how could it be different -- that they are all acive and wide open. Mike P.S. thanks a lot! From Firewalls-Owner@GreatCircle.COM Fri Jan 21 12:24:53 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14412; Fri, 21 Jan 94 20:07:21 GMT Received: from clavin.uprc.com (uprc.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14382; Fri, 21 Jan 94 12:07:06 PST Received: from cygnus.uprc.com by clavin.uprc.com (4.1/3.2.012693-Union Pacific Resources Company); id AA10736 for firewalls@greatcircle.com; Fri, 21 Jan 94 14:07:29 CST Received: by cygnus.uprc.com (5.0/SMI-SVR4) id AA05684; Fri, 21 Jan 1994 14:08:43 +0600 Date: Fri, 21 Jan 1994 14:08:43 +0600 From: lacoursj@uprc.com (Jeffrey D. LaCoursiere) Message-Id: <9401212008.AA05684@cygnus.uprc.com> To: firewalls@greatcircle.com Subject: Re: Modem scanner & living with reverse DNS lookups Cc: harker@harker.com, firewalls@GreatCircle.COM X-Sun-Charset: US-ASCII Content-Length: 515 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > > I hate to tell you this, but its trivial to write a program to > > run through a segment of the IP address space, looking for ports > > that are 'active'. > > And if you're trying to find a particular flavor box, you can just > send SNMP queries for system.sysObjectID... You don't need names to > figure out what the box is in many cases. > > louie > Am I missing something or wouldn't this be difficult to do through a properly configured firewall? Jeff LaCoursiere Network Admin UPRC Ft. Worth, TX From Firewalls-Owner@GreatCircle.COM Fri Jan 21 20:50:28 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14701; Fri, 21 Jan 94 20:50:28 GMT Received: from thor.tjhsst.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14694; Fri, 21 Jan 94 12:50:18 PST Received: by thor.tjhsst.edu (Smail3.1.28.1 #1) id m0pNSpo-000DOgC; Fri, 21 Jan 94 15:52 EST Message-Id: To: aegl@stratus.swdc.stratus.com Cc: firewalls@greatcircle.com Subject: Re: Modem scanner (and split DNS) In-Reply-To: Your message of "Fri, 21 Jan 1994 11:46:50 EST." <9401211946.AA16648@swdc.stratus.com> Date: Fri, 21 Jan 1994 15:51:58 EST From: Craig Metz Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9401211946.AA16648@swdc.stratus.com>, you write: >Don't zone transfers come in as TCP connections to port 53, while regular >lookups are UDP port 53. This makes it easy (if you have a filtering >router between your DNS server and the rest of the world) to only allow >zone transfers to your secondaries. I guess you'd just have to ask your >secondaries not to allow zone transfers. BIND 4.9 and higher supports the 'xfrnets' command which restricts zone transfers to a known list of hosts. -Craig From Firewalls-Owner@GreatCircle.COM Sat Jan 22 00:15:33 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15391; Sat, 22 Jan 94 00:15:33 GMT Received: from svin01.win.tue.nl by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15374; Fri, 21 Jan 94 16:15:23 PST Received: from wzv.win.tue.nl by svin01.win.tue.nl (8.6.4/1.45) id BAA26626; Sat, 22 Jan 1994 01:16:56 +0100 Received: from localhost by wzv.win.tue.nl (8.6.4/1.45) id WAA13750; Fri, 21 Jan 1994 22:54:54 +0100 From: wietse@wzv.win.tue.nl (Wietse Venema) Message-Id: <199401212154.WAA13750@wzv.win.tue.nl> Subject: Re: portmap To: hobbit@babyoil.ftp.com (*Hobbit*) Date: Fri, 21 Jan 94 22:54:53 MET Cc: firewalls@greatcircle.com In-Reply-To: <9401211715.AA23360@babyoil.ftp.com>; from "*Hobbit*" at Jan 21, 94 12:15 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Is there any other porting effort in the works, particularly in the direction > of SV compliance? Some observed problems off the top of my head: > > HPUX tends to spin off a zillion duplicate portmap processes as > requests come in. Fixed in the current release, thanks to Lionel Cons at CERN. > Solaris has "rpcbind" or something, which apparently isn't the > same. A proof-of-concept rpcbind daemon can be found on ftp.win.tue.nl, in /pub/security. This is a fixed version of the rpcbind sources in the tirpcsrc distribution. Tested lightly with Solaris 2.2. It misses a few features but sofar nothing broke on my system. > OSF/1 tends to not send any responses to the caller, even though > things like pmap_set *do* get through and have effect. > > It won't even *build* on an AIX box, due to missing .h files. Reportedly, it is running on several AIX boxes. Perhaps the missing includes are part of an optional package? Wietse From Firewalls-Owner@GreatCircle.COM Sat Jan 22 01:23:40 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15531; Sat, 22 Jan 94 01:23:40 GMT Received: from welch.ncd.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15522; Fri, 21 Jan 94 17:23:30 PST Received: from bryant.ncd.com (mfrost@bryant.ncd.com [192.43.159.209]) by welch.ncd.com (8.6.5/8.6.4) with ESMTP id RAA13070; Fri, 21 Jan 1994 17:25:18 -0800 Received: from localhost (mfrost@localhost) by bryant.ncd.com (8.6.5/8.6.5.Beta11) id RAA02737; Fri, 21 Jan 1994 17:25:21 -0800 From: mfrost@ncd.com (Mark Frost) Message-Id: <9401211725.ZM2735@bryant.ncd.com> Date: Fri, 21 Jan 1994 17:25:20 -0800 In-Reply-To: Brent Chapman "Re: Modem scanner & living with reverse DNS lookups" (Jan 21, 11:56) References: <9401211907.AA13703@mycroft.GreatCircle.COM> X-Mailer: Z-Mail (2.1.5 09aug93) To: Brent Chapman Subject: Re: Modem scanner & living with reverse DNS lookups Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Jan 21, 11:56, Brent Chapman wrote: > Subject: Re: Modem scanner & living with reverse DNS lookups > I think both sides of the "hide internal DNS info" versus "don't hide > internal DNS info" have been well presented here, but the debate is > now showing signs of turning into another flame war. At this point, > let's just agree to disagree, and leave it at that. > > -Brent >-- End of excerpt from Brent Chapman I dunno, I actually rather like how this is going. We too have a split DNS for the "defensive" reasons stated by some. Yet I too am bothered by the problems that having a split DNS causes. So I sort of straddle both sides of the issue. We've seen people basically flesh out both sides of this argument -- why split DNS is good to do and why it's bad to do. I'd be very happy to be able to do split DNS, *and* not have the problems with remote servers that I am having at a few sites. It would be nice if we (the firewallers) could somehow figure out a good compromise solution... -mark From Firewalls-Owner@GreatCircle.COM Sat Jan 22 01:27:35 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15551; Sat, 22 Jan 94 01:27:35 GMT Received: from welch.ncd.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15544; Fri, 21 Jan 94 17:27:22 PST Received: from bryant.ncd.com (mfrost@bryant.ncd.com [192.43.159.209]) by welch.ncd.com (8.6.5/8.6.4) with ESMTP id RAA13318; Fri, 21 Jan 1994 17:29:11 -0800 Received: from localhost (mfrost@localhost) by bryant.ncd.com (8.6.5/8.6.5.Beta11) id RAA02766; Fri, 21 Jan 1994 17:29:15 -0800 From: mfrost@ncd.com (Mark Frost) Message-Id: <9401211729.ZM2764@bryant.ncd.com> Date: Fri, 21 Jan 1994 17:29:14 -0800 In-Reply-To: aegl@stratus.swdc.stratus.com "Re: Modem scanner (and split DNS)" (Jan 21, 12:27) References: <9401211946.AA16648@swdc.stratus.com> X-Mailer: Z-Mail (2.1.5 09aug93) To: aegl@stratus.swdc.stratus.com Subject: Re: Modem scanner (and split DNS) Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Jan 21, 12:27, aegl@stratus.swdc.stratus.com wrote: > Subject: Re: Modem scanner (and split DNS) > > On the other hand, there is no reason not to make the buggers work for > > their access failures. This is probably a FAQ but how do you restrict who > > can do zone transfers? Is it possible to persuade network vendors to > > restrict zone transfers from the secondary they are running for us? (page > > reference in O'Reilly DNS + BIND is enough. I can't find it) > > Don't zone transfers come in as TCP connections to port 53, while regular > lookups are UDP port 53. This makes it easy (if you have a filtering > router between your DNS server and the rest of the world) to only allow > zone transfers to your secondaries. I guess you'd just have to ask your > secondaries not to allow zone transfers. > > This is just a delaying tactic though ... as an attacker can ask for PTR > records for every possible address on your net(s) (which doesn't take long > if you only have a bunch of class-C nets). > > -Tony >-- End of excerpt from aegl@stratus.swdc.stratus.com Yes that's what TCP connections are *mostly* for on port 53, but not always. There are times when the return packet of DNS info is larger than a udp packet. An error is generated and then the requested info is resent using TCP. We found recently that because our router was blocking 53/tcp that our mail gateway's sendmail was mysteriously unable to send a number of mail messages because of strange dns errors. It took a while for me to figure this one out, but eventually it was discovered that the sites in question had large lists of NS records. As soon as we opened up 53/tcp the mail flowed through fine. BIND 4.9.2 has an option in the named.boot file that (something like "xfernets" or something) that allows you to specify who can and can't do zone transfers. Of course that only slows someone down -- it doesn't prevent a probe of address ranges. -mark From Firewalls-Owner@GreatCircle.COM Sat Jan 22 02:33:35 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15768; Sat, 22 Jan 94 02:33:35 GMT Received: from ipcit1.canadair.ca by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15761; Fri, 21 Jan 94 18:33:24 PST Received: from moosehead.eng.canadair.ca by ipcit1.canadair.ca with SMTP id AA09213 (5.65+/IDA-1.3.5 for firewalls@greatcircle.com); Fri, 21 Jan 94 21:35:06 -0500 Received: from localhost by moosehead.eng.canadair.ca with SMTP id AA07248 (5.65+/IDA-1.3.5 for firewalls@greatcircle.com); Fri, 21 Jan 94 21:29:18 -0500 Message-Id: <9401220229.AA07248@moosehead.eng.canadair.ca> To: mfrost@ncd.com (Mark Frost) Cc: firewalls@greatcircle.com Subject: Re: Modem scanner & living with reverse DNS lookups In-Reply-To: Your message of "Fri, 21 Jan 94 17:25:20 PST." <9401211725.ZM2735@bryant.ncd.com> Date: Fri, 21 Jan 94 21:29:17 -0500 From: "Marc P. Rinfret" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > We've seen people basically flesh out both sides of this argument -- why > split DNS is good to do and why it's bad to do. I'd be very happy to > be able to do split DNS, *and* not have the problems with remote servers > that I am having at a few sites. It would be nice if we (the firewallers) > could somehow figure out a good compromise solution... > Why not use proxies (aka "application level gateway", socks, igateway, ...)? We have a split DNS, but because we use proxies we don't have any problems. All the connections appear to originate from a single host, which is properly advertised. In our situation we have no choice but to use proxies as our Internet connection is through a single address across a PPP link. I believe proxies could be used effectively even if you are directly connected. There are arguments against proxies, they may not be available for all potential services, they require special client programs, performance issues,... But ... if you do want a split DNS maybe you should consider offering proxy services. I believe they do offer "a good compromise solution". Marc. From Firewalls-Owner@GreatCircle.COM Sat Jan 22 14:11:02 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA17571; Sat, 22 Jan 94 14:11:02 GMT Received: from srv.cip.physik.tu-muenchen.de by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA17564; Sat, 22 Jan 94 06:10:52 PST Received: from comserv.cip.physik.tu-muenchen.de by srv.cip.physik.tu-muenchen.de with SMTP id AA13871 for (5.67a/IDA-1.5/bs03); Sat, 22 Jan 1994 15:12:02 +0100 Message-Id: <199401221412.AA13871@srv.cip.physik.tu-muenchen.de> To: Craig Metz Cc: firewalls@greatcircle.com Subject: Re: Implementing ``good'' firewall router code In-Reply-To: Your message of "Thu, 20 Jan 94 19:26:53 EST." Date: Sat, 22 Jan 94 15:12:00 +0100 From: Bernhard.Schneck@Physik.TU-Muenchen.DE Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message you write: > [... about implementing a packet filter under Linux ...] Take a look at Jeff Mogul's screend package, available for free from gatekeeper.dec.com. It has been ported eg to BSD/386, but the port has not yet been released (there were some restrictions in the original DEC license terms, but these are resolved now as far as I know). \Bernhard. From Firewalls-Owner@GreatCircle.COM Sat Jan 22 17:35:44 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18065; Sat, 22 Jan 94 17:35:44 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18058; Sat, 22 Jan 94 09:35:37 PST Received: by relay.tis.com; id AA29129; Sat, 22 Jan 94 12:37:27 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma029127; Sat Jan 22 12:37:14 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA12075; Sat, 22 Jan 94 12:36:52 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA06634; Sat, 22 Jan 94 12:36:51 EST Date: Sat, 22 Jan 94 12:36:51 EST From: mjr@tis.com Message-Id: <9401221736.AA06634@otter.tis.com> To: firewalls@GreatCircle.COM, robert@puente.jpl.nasa.gov Subject: Re: Summary:Telnet/Ftp through a firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Is there a FAQ for this newsgroup??? If not, there should be... I've got an embryonic one I've sent to folks for review but I haven't rolled their suggestions back into it yet. It's almost "done". mjr. From Firewalls-Owner@GreatCircle.COM Sat Jan 22 18:09:48 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18193; Sat, 22 Jan 94 18:09:48 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18186; Sat, 22 Jan 94 10:09:38 PST Received: by relay.tis.com; id AA29285; Sat, 22 Jan 94 13:11:29 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma029282; Sat Jan 22 13:11:03 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA12495; Sat, 22 Jan 94 13:10:40 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA06705; Sat, 22 Jan 94 13:10:39 EST Date: Sat, 22 Jan 94 13:10:39 EST From: mjr@tis.com Message-Id: <9401221810.AA06705@otter.tis.com> To: harker@harker.com, jim@Tadpole.COM Subject: Re: Modem scanner & living with reverse DNS lookups Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I hate to tell you this, but its trivial to write a program to >run through a segment of the IP address space, looking for ports >that are 'active'. Such a program can even gain a fair amount >of parallism by using as many descriptors (e.g. sockets) as the >system will let it have. (For instance, SunOS 4.1.X will let you >use up to 256 file descriptors per process, you'll need one for >output to some file, other process, ...). A tool for doing exactly this is included with the TIS firewall toolkit. Its purpose is to permit administrators to verify that they have correctly disabled services they think they have disabled, and that they have correctly blocked traffic to networks they think they have blocked traffic to. (check fwtk/tools/admin/netscan and fwtk/tools/admin/portscan for source) One observation I'd like to make about the whole DNS hiding question revolves around the fundamentals of how you're designing your firewall. If your object is to hide a host, then the way to do it is not to hide its name, but to ensure that the outside cannot route traffic to it. "Hidden" on a network should not mean "hard to see" -- it should mean "invisible." DNS names really should only pose a threat if you're doing sensitive work and the names indicate it (e.g., "patent-applications-fileserver.fratz.com") - and anyone who names workstations in such a manner has deeper problems than a mere firewall can solve. Put another way, if the security of your network relies on your hiding DNS information, you have a problem. The cry "security through obscurity" is often heard in this list and on the 'net. What you have to remember is that the idea is that your security should not *RELY* on obscurity. That doesn't mean that obscurity can't help your security. Anything that makes the other guy's life a bit harder should be evaluated for its usefulness. Which brings me back to hiding DNS names. It takes effort and inconvenience to hide DNS names. It may help your security a little bit, but it's going to help not a whit against anyone but the most novice attacker. The expected benefit of hiding DNS names is, IMHO, rather low (near zero) and doesn't usually pay for the effort required to do it. Your actual mileage may vary. mjr. From Firewalls-Owner@GreatCircle.COM Sat Jan 22 18:32:51 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18271; Sat, 22 Jan 94 18:32:51 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18264; Sat, 22 Jan 94 10:32:41 PST Received: by relay.tis.com; id AA29432; Sat, 22 Jan 94 13:34:30 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma029430; Sat Jan 22 13:34:28 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA12966; Sat, 22 Jan 94 13:34:05 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA06734; Sat, 22 Jan 94 13:34:04 EST Date: Sat, 22 Jan 94 13:34:04 EST From: mjr@tis.com Message-Id: <9401221834.AA06734@otter.tis.com> To: firewalls@GreatCircle.COM, lacoursj@uprc.com Subject: Re: Modem scanner & living with reverse DNS lookups Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jeff LaCoursiere writes: >Am I missing something or wouldn't this be difficult to do through >a properly configured firewall? Well, that begs the question of what you consider a properly configured firewall. ;) The model of firewalls that we recommend is to not have any direct IP traffic between the protected "inside" network and the internet. So, yes, it'd be rather hard to probe someone's terminal server in that kind of configuration. Not all firewalls are so (searching for the right word) absolutist about blocking traffic. Another thing to remember is that (unless I misread Alastair's original mail) the attempts never actually *got* to the annex, they simply probed that set of addresses -- clearly they were *trying* to make a run on the annex boxes. ...Which brings us to the issue of logging and warning administrators when something suspicious happens. As I get older and lazier I am less and less interested in chasing down attempts to break into systems that are doomed to failure if everything performs as its supposed to. I find it's more effective to shift one's focus from having the alarms go off whenever someone knocks on the door, to having the alarms go off whenever someone is detected inside the house. If I got worried every time that someone tried to FTP the password file off whitehouse.gov's FTP area, my ulcers would be the size of Nebraska by now. On the other hand, I'd be deeply concerned if I ever noticed anyone other than a small list of people logged into the machine!!! Unless you're actually interested in responding to all the warning messages, then it's not worth getting them. Save them, by all means, in case a *real* alarm goes off, but otherwise you're just letting some dumb kid waste your time. I'm perpetually reminded of the word-play between Capt Nemo and the adventurers on the Nautilus, "Is this an accident, or an incident??" they'd ask the captain, and he'd imperturbably reply, "This is an incident." -- Part of threat assessment is figuring out what a real threat is, so you can correctly gauge the level of response that it requires. mjr. From Firewalls-Owner@GreatCircle.COM Mon Jan 24 04:04:04 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26942; Mon, 24 Jan 94 04:04:04 GMT Received: from kowari.cpsg.com.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26935; Sun, 23 Jan 94 20:03:45 PST Received: from bohra.cpsg.com.au by kowari.cpsg.com.au with SMTP (5.65c/DEC-Ultrix/4.3) id AA29512; Mon, 24 Jan 1994 15:04:59 +1100 Received: from localhost (als@localhost) by bohra.cpsg.com.au (8.6.4/8.6.4) id PAA17600 for Firewalls@GreatCircle.COM; Mon, 24 Jan 1994 15:04:54 +1100 Received: from kowari.cpsg.com.au (kowari.cpsg.com.au [138.79.3.5]) by bohra.cpsg.com.au (8.6.4/8.6.4) with SMTP id PAA11478 for ; Mon, 24 Jan 1994 15:01:22 +1100 Received: from marloo.cpsg.com.au by kowari.cpsg.com.au with SMTP (5.65c/DEC-Ultrix/4.3) id AA29449; Mon, 24 Jan 1994 15:01:16 +1100 Received: by marloo.cpsg.com.au (1.37.109.4/16.2) id AA17553; Mon, 24 Jan 94 15:01:14 +1100 To: usenet@cpsg.com.au Path: cpsg.com.au!not-for-mail From: als@cpsg.com.au (Anthony Shipman) Newsgroups: cpg.lists.firewalls Subject: Re: Modem scanner & living with reverse DNS lookups Date: 24 Jan 1994 15:01:12 +1100 Organization: Computer Power Software Group Pty Ltd Lines: 24 Message-Id: <2hvh68$h4e@marloo.cpsg.com.au> References: <9401211725.ZM2735@bryant.ncd.com> X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk mfrost@ncd.COM (Mark Frost) writes: >We've seen people basically flesh out both sides of this argument -- why >split DNS is good to do and why it's bad to do. I'd be very happy to >be able to do split DNS, *and* not have the problems with remote servers >that I am having at a few sites. It would be nice if we (the firewallers) >could somehow figure out a good compromise solution... We use a split DNS on a firewall and the SOCKS software. All external ftp connections appear to come from the firewall machine where the SOCKS daemon runs. This gets me into ftp.uu.net which does reverse lookups. The only down-side is various ftp daemons think they can verify the e-mail address I use as the password by doing a reverse-lookup on the firewall address. This is dumb. My e-mail address is an MX record so won't ever match any DNS A record. -- Anthony Shipman "You've got to be taught before it's too late, CP Software Export Pty Ltd, Before you are six or seven or eight, 4th Flr, 493 St Kilda Rd, To hate all the people your relatives hate, Melbourne, Australia, 3121 You've got to be carefully taught." R&H E-mail: als@cpsg.com.au, Phone: +61 3 2432374 From Firewalls-Owner@GreatCircle.COM Mon Jan 24 05:11:01 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27128; Mon, 24 Jan 94 05:11:01 GMT Received: from MCIGATEWAY.MCIMail.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27121; Sun, 23 Jan 94 21:10:46 PST Received: by MCIGATEWAY.MCIMail.com id aa18687; 24 Jan 94 5:05 GMT Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ak17017; 24 Jan 94 4:38 GMT Date: Sun, 23 Jan 94 23:42 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Mark Frost Cc: firewalls Subject: Restricting Zone transfers Message-Id: <40940124044204/0003858921NA2EM@mcimail.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >BIND 4.9.2 has an option in the named.boot file that (something like >"xfernets" or something) that allows you to specify who can and can't do >zone transfers. >Of course that only slows someone down -- it doesn't prevent a probe of >address ranges. With a recursive LS query can't they learn your whole tree anyway? And what about DiG? Does it do zone transfers to get the info, or does it have another mechanism? Bob Moskowitz Chrysler From Firewalls-Owner@GreatCircle.COM Mon Jan 24 12:57:43 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29225; Mon, 24 Jan 94 12:57:43 GMT Received: from MCIGATEWAY.MCIMail.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29217; Mon, 24 Jan 94 04:57:26 PST Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ab16054; 24 Jan 94 12:46 GMT Date: Mon, 24 Jan 94 07:47 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Anthony Shipman To: firewalls Subject: Re: Modem scanner & living with reverse DNS lookups Message-Id: <55940124124755/0003858921NA3EM@mcimail.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >The only down-side is various ftp daemons think they can verify the e-mail >address I use as the password by doing a reverse-lookup on the firewall >address. This is dumb. My e-mail address is an MX record so won't ever >match any DNS A record. And as if I am not going to typo my e-mail address. That is so patently rediculous. For me it is even worst. Until Friday (our SMTP on the firewall is finally running), my EMAIL had NOTHING to do with my firewall! Bob From Firewalls-Owner@GreatCircle.COM Mon Jan 24 13:58:27 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29436; Mon, 24 Jan 94 13:58:27 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29429; Mon, 24 Jan 94 05:58:21 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwafw01950; Mon, 24 Jan 94 09:00:09 -0500 Message-Id: <9401241400.AAwafw01950@relay2.UU.NET> Received: from debbie.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 085816.28301; Mon, 24 Jan 1994 08:58:16 EST Received: by debbie.fbsw.tt.com (16.6/16.2.0) id AA05029; Mon, 24 Jan 94 08:56:33 -0500 From: John Hasselkus Subject: Re: Pings... To: uunet!GreatCircle.COM!Firewalls@uunet.UU.NET Date: Mon, 24 Jan 1994 08:56:33 -0500 (EST) In-Reply-To: <9401220900.AA16678@mycroft.GreatCircle.COM> from "GreatCircle.COM!Firewalls-Digest-Owner" at Jan 22, 94 01:00:12 am Organization: Telecommunications Techniques Corp. X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 209 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk OK, so we've seen there all kinds of holes in simply filtering ports 1-24, 26-1023, so what _is_ the proper way to configure a router when acting as as part of a firewall. -- John Hasselkus johnh@fbsw.tt.com From Firewalls-Owner@GreatCircle.COM Mon Jan 24 07:17:35 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29660; Mon, 24 Jan 94 15:14:51 GMT Received: from checkpoint.brm.co.il (doors.brm.co.il) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29644; Mon, 24 Jan 94 07:14:11 PST Received: from monk.UUCP by checkpoint.brm.co.il (4.1/SMI-4.0) id AA06133; Mon, 24 Jan 94 17:18:04 IST Received: by checkpoint.brm.co.il (4.1/SMI-4.1) id AA01743; Mon, 24 Jan 94 17:13:27 IST Date: Mon, 24 Jan 94 17:13:27 IST From: gil@checkpoint.brm.co.il (Gil Shwed) Message-Id: <9401241513.AA01743@checkpoint.brm.co.il> To: Firewalls@GreatCircle.COM, johnh@fbsw.tt.com Subject: Re: Pings... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk John Hasselkus wrote: > OK, so we've seen there all kinds of holes in simply filtering ports 1-24, > 26-1023, so what _is_ the proper way to configure a router when acting as > as part of a firewall. One way is simply to block everything but port 23, then you have SMTP but you cannot connect to the outside. Another solution is to allow only established connections (available on CISCO routers) and port 23. In this solution you can connect to the outside, yet ftp won't work. You also won't have any udp (archie, etc.) connections. [In both cases you also need to enable dns port 53 udp for some cases]. In short, there is no "good" solution with routers which lets you have "Connectivity with Security". -- Gil Shwed -- CheckPoint Software Technologies. From Firewalls-Owner@GreatCircle.COM Mon Jan 24 16:37:46 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00136; Mon, 24 Jan 94 16:37:46 GMT Received: from cgi.com (cggate.cgi.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00126; Mon, 24 Jan 94 08:37:36 PST Received: by cgise (4.1/3.1.090690-CGI) id AA22960; Mon, 24 Jan 94 11:43:25 EST Message-Id: <9401241643.AA22960@cgise> Date: Mon, 24 Jan 94 11:43:24 EST X-Mailer: Mail User's Shell (6.5 4/17/89) From: espiritu@cgi.com (Rex Espiritu) To: firewalls@greatcircle.com Subject: igopher (?) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I seem to recall hearing about a gopher proxy agent/software for Sun's Igateway firewall package at the Nov. LISA/Usenix Conference. Is this available via ftp somewhere on the net? Any information/pointers/assistance on this and/or any other igateway proxy agent(s) [in addition to iftp/itelnet] would be greatly appreciated. (We are considering using socks at a later date, but would like to keep using Igateway for the time being.) Thanks in advance, Rex espiritu@cgi.com From Firewalls-Owner@GreatCircle.COM Mon Jan 24 16:43:17 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00158; Mon, 24 Jan 94 16:43:17 GMT Received: from deshaw.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00151; Mon, 24 Jan 94 08:42:58 PST Received: from deshaw.com by deshaw.com with SMTP id AA00495 (5.65c/IDA-1.4.4 for ); Mon, 24 Jan 1994 11:44:41 -0500 Message-Id: <199401241644.AA00495@deshaw.com> To: Firewalls@greatcircle.com Subject: Re: Pings... Date: Mon, 24 Jan 94 11:44:41 -0500 From: Mark Moraes Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk John Hasselkus wrote: | OK, so we've seen there all kinds of holes in simply filtering ports 1-24, | 26-1023, so what _is_ the proper way to configure a router when acting as | as part of a firewall. Q. How do I configure my packet filter? A. Drop all incoming traffic except the ports you need. Examples include: - SMTP (25/tcp) to your mail receiver(s) - Nameserver traffic (53/udp) and zone transfers (53/tcp) - Network Time protocol traffic (123/udp, 123/tcp) if you care about this. - NNTP (119/tcp) if you care about this. Configure your nntpd to only accept xfer connections from your feeds, to provide the Internet a minimal level of protection against news forgery :-) - you may want a few other services -- eg. dirsrv (1525/udp) for the Prospero Archie client, but be careful. This applies to any services you want to enable. Log those services with a TCP wrapper package. Never allow random UDP in, especially NFS, YP and other RPC services. This was the easy part. The next step depends on whether you have a "bastion host" (see the firewall docs on ftp.greatcircle.com) and how much access to the Internet you wish to give your users. If you have bastion host and are using proxy commands to go through that host for Internet access, then you're ok. (well, you'll have a different set of problems, but they don't have to do with the router -- you now get to deal with every new protocol and client and make it deal with the proxy). If you don't have a bastion host and are just relying on the router to provide security: Problem 1. TCP connections are bidirectional, obviously -- your firewall as configured above will drop all incoming packets, making TCP sessions impossible. Your users cannot telnet out, for example. (You may well consider this a feature) If you want your users to be able to make TCP connections to the outside world, then you have to let in incoming TCP packets to ports > 1024 EXCEPT those that have the SYN bit set. (the > 1024 is a Unix restriction, by the way) See <9401141600.AA07913@mycroft.GreatCircle.COM> in the archives for Steve Bellovin's explanation on this, or follow his recommendation and get Richard Stevens' new book ``TCP/IP Illustrated''. If your firewall doesn't let you drop SYN packets, let in everything above 1024 except for things like X, OpenWindows, Annexes, SQL/database servers, etc (tedious, time-consuming process that requires you to make sure you know every port that's being listened on in any internal host or network appliance on your net), or fix all your external applications to bind to a specific range of ports and only let those in, making sure you don't have any daemons listening in that range! Problem 2. ftp requires that the remote host open a connection to the local host on a dynamically allocated port for the returned data. (There is a statically allocated ftp-data port, but it's a bit of a nuisance to use it -- only one user can use ftp at a time on a given machine, and there's a delay of at least a minute between transfers). There's stuff in the archives about this, specifically a PASV mode patches for both ftp and ftpd, there are proxy ftp (and other client) toolkits. Recommended reading from the archives: <199311010132.AA13782@quack.kfu.com> Nick Sayer <9311102206.AA12182@futureworld.advtech.uswest.com> Brad Huntting <9312151417.AA14556@mycroft.GreatCircle.COM> smb@research.att.com <9312151615.AA15097@mycroft.GreatCircle.COM> Brent Chapman <199312261647.AA12599@quack.kfu.com> Nick Sayer <9401191640.AA13454@arian.universe> hsafai@esri.com (Houman Safai ) <9401200953.AA03582@tadpole.tadpole.com> jim@Tadpole.COM (Jim Thompson) <9401141600.AA07913@mycroft.GreatCircle.COM> smb@research.att.com Mark. From Firewalls-Owner@GreatCircle.COM Mon Jan 24 17:24:39 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00379; Mon, 24 Jan 94 17:24:39 GMT Received: from mail2.uunet.ca (spectre.uunet.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00369; Mon, 24 Jan 94 09:24:28 PST Received: from cchtor.cch.com ([192.139.241.2]) by spectre.uunet.ca with SMTP id <32745(1)>; Mon, 24 Jan 1994 12:25:53 -0500 Received: from localhost (larry@localhost) by cchtor.cch.com (8.6.4/8.6.4) id MAA09946 for Firewalls@GreatCircle.COM; Mon, 24 Jan 1994 12:28:31 -0500 Date: Mon, 24 Jan 1994 12:28:31 -0500 From: Larry Chin Message-Id: <199401241728.MAA09946@cchtor.cch.com> To: Firewalls@GreatCircle.COM Subject: ANS Interlock product Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello all, I was wondering if anyone out there has used the Interlock product from ANS and if you have what are your opinions of it ? If you are so inclined perhaps you could send me your experiences, both good and bad as well as any comments or information that you feel inclined to provide. Thanks muchly, Mon Jan 24 12:27:19 EST 1994 =========================================================================== Larry Chin {larry@cchtor.cch.com} CCH Canadian Ltd. System Administrator 6 Garamond Court Research and Development North York, Ontario. (416) 441-4001 ext. 349 M3C 1Z5 =========================================================================== A new supply of round tuits has arrived and are available from Mary. Anyone who has been putting off work until they got a "round tuit" now has no excuse for further procrastination. From Firewalls-Owner@GreatCircle.COM Mon Jan 24 17:40:37 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00491; Mon, 24 Jan 94 17:40:37 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00483; Mon, 24 Jan 94 09:40:15 PST Message-Id: <9401241740.AA00483@mycroft.GreatCircle.COM> To: gil@checkpoint.brm.co.il (Gil Shwed) Cc: Firewalls@GreatCircle.COM, johnh@fbsw.tt.com Subject: Re: Pings... In-Reply-To: Your message of Mon, 24 Jan 94 17:13:27 IST Date: Mon, 24 Jan 1994 09:40:13 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk gil@checkpoint.brm.co.il (Gil Shwed) writes: # # John Hasselkus wrote: # > OK, so we've seen there all kinds of holes in simply filtering ports 1-24, # > 26-1023, so what _is_ the proper way to configure a router when acting as # > as part of a firewall. # One way is simply to block everything but port 23, then you have SMTP # but you cannot connect to the outside. # Another solution is to allow only established connections (available # on CISCO routers) and port 23. In this solution you can connect to the # outside, yet ftp won't work. You also won't have any udp (archie, etc.) # connections. # [In both cases you also need to enable dns port 53 udp for some cases]. # # In short, there is no "good" solution with routers which lets you have # "Connectivity with Security". Whoa!!! That's a hell of a general conclusion to make... First, define "good". This is very site dependant. Then, define "connectivity". Again, very site dependant. Finally, define "security". See what I'm getting at, here? I'd agree that there is no _simple_ solution, and there is no solution that I'm personally happy with that involves only routers (i.e., that doesn't also involve a bastion host), but I wouldn't want people to get the idea from your statement above that routers are useless for firewalls; far from it! They can be an extremely useful, or even a key, _component_ of a firewall. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Mon Jan 24 10:07:36 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00623; Mon, 24 Jan 94 17:54:04 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00615; Mon, 24 Jan 94 09:53:30 PST Message-Id: <9401241753.AA00615@mycroft.GreatCircle.COM> To: Mark Moraes Cc: Firewalls@greatcircle.com Subject: Re: Pings... In-Reply-To: Your message of Mon, 24 Jan 94 11:44:41 -0500 Date: Mon, 24 Jan 1994 09:53:28 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mark Moraes writes: # Recommended reading from the archives: # <199311010132.AA13782@quack.kfu.com> Nick Sayer # <9311102206.AA12182@futureworld.advtech.uswest.com> Brad Huntting # <9312151417.AA14556@mycroft.GreatCircle.COM> smb@research.att.com # <9312151615.AA15097@mycroft.GreatCircle.COM> Brent Chapman # <199312261647.AA12599@quack.kfu.com> Nick Sayer # <9401191640.AA13454@arian.universe> hsafai@esri.com (Houman Safai ) # <9401200953.AA03582@tadpole.tadpole.com> jim@Tadpole.COM (Jim Thompson) # <9401141600.AA07913@mycroft.GreatCircle.COM> smb@research.att.com Before everybody goes and grabs the _whole_ archive to get these messages, I've extracted them into a file in the anonymous FTP archive on FTP.GreatCircle.COM: pub/firewalls/moraes-selection.Z -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Mon Jan 24 18:47:30 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01112; Mon, 24 Jan 94 18:47:30 GMT Received: from checkpoint.brm.co.il (doors.brm.co.il) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01105; Mon, 24 Jan 94 10:47:15 PST Received: from monk.UUCP by checkpoint.brm.co.il (4.1/SMI-4.0) id AA07206; Mon, 24 Jan 94 20:51:27 IST Received: by checkpoint.brm.co.il (4.1/SMI-4.1) id AA03856; Mon, 24 Jan 94 20:46:24 IST Date: Mon, 24 Jan 94 20:46:24 IST From: gil@checkpoint.brm.co.il (Gil Shwed) Message-Id: <9401241846.AA03856@checkpoint.brm.co.il> To: gil@checkpoint.brm.co.il, brent@GreatCircle.COM Subject: Re: Pings... Cc: Firewalls@GreatCircle.COM, johnh@fbsw.tt.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brent Chapman wrote: > gil@checkpoint.brm.co.il (Gil Shwed) writes:> > # > # John Hasselkus wrote: > # > OK, so we've seen there all kinds of holes in simply filtering ports 1-24, > # > 26-1023, so what _is_ the proper way to configure a router when acting as > # > as part of a firewall. > # One way is simply to block everything but port 23, then you have SMTP > # but you cannot connect to the outside. > # Another solution is to allow only established connections (available > # on CISCO routers) and port 23. In this solution you can connect to the > # outside, yet ftp won't work. You also won't have any udp (archie, etc.) > # connections. > # [In both cases you also need to enable dns port 53 udp for some cases]. > # > # In short, there is no "good" solution with routers which lets you have > # "Connectivity with Security". > > Whoa!!! That's a hell of a general conclusion to make... > > First, define "good". This is very site dependant. > Then, define "connectivity". Again, very site dependant. > Finally, define "security". See what I'm getting at, here? > > I'd agree that there is no _simple_ solution, and there is no solution > that I'm personally happy with that involves only routers (i.e., that > doesn't also involve a bastion host), but I wouldn't want people to > get the idea from your statement above that routers are useless for > firewalls; far from it! They can be an extremely useful, or even a > key, _component_ of a firewall. > > I agree security is a subjective term, and is "site dependant" that sense. However, a "Good" solution doesn't leave any communication resource (computer, network, port, service, etc.) uncontrolled, and let you verify it's correctness and operation. "Connectivity" is the ability to communicate transparently from anywhere you want in your internal network to anywhere you like, using all the avialable services. For the definition of "Security" - see "Good". I don't think routers are useless when securing a network, and I do agree that they can play a key role in securing an Internet (or any other) inter-network connection. I still believe that you cannot get true good "Connectivity with Security" using routers only. Actually, using the above definitions there aren't many other good solution I know about. I do think that any site would prefer and benefit from a "good connectivity with security" solution. -- Gil Shwed -- CheckPoint Software Technologies From Firewalls-Owner@GreatCircle.COM Tue Jan 25 00:47:40 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04729; Tue, 25 Jan 94 00:47:40 GMT Received: from asilomar.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04721; Mon, 24 Jan 94 16:47:32 PST Received: from localhost by asilomar.netcom.com (8.6.4/SMI-4.1) id QAA04024; Mon, 24 Jan 1994 16:52:33 -0800 Date: Mon, 24 Jan 1994 16:52:33 -0800 From: owen@netcom.com Message-Id: <199401250052.QAA04024@asilomar.netcom.com> To: firewalls@greatcircle.com Subject: Re: schizoprenic dns Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > - - The external map can list only the MX records which really are visible from > the outside, so outsiders don't have to go through the list of hidden > MXs, timing out, until they finally locate your external mail relay. In my opinion, this simple courtesy to the other internet sites that send mail to your site is well worth the effort. You would be amazed at the amount of unnecessary process-time, network traffic, etc. that this can and will eliminate. > - - Your external map will probably be MUCH smaller, and won't change nearly > as often as the internal map. This is a nice thing to do for your off- > site secondaries. Yep. > - - You can use a wildcard MX, which lets mail be relayed to internal systems > the moment the system is set up, instead of waiting for the zone transfers > to occur to all the secondaries which need to know about it. (I have > mixed feelings about this one - if you make a tiny mistake and the wildcard > MX infects the internal DNS, you're in deep trouble.) Actually, as long as the wildcard MX doesn't override the internal information, and the internal information is at a lower number (higher preference) in it's MX records, it shouldn't affect things too much. > - - The external map can list only the specific interfaces on multihomed hosts > which are reachable from outside. This eliminates more timeouts/retries. Yep. > - - As Andy says, the external map can contain things that you -want- people > to notice: TXT records with contact information, obvious aliases for > ftp, archie or gopher (or the lack of those aliases), or whatever. It's > not buried in 1000s of lines of A records and repetitive MX records. Very true. Side bennefit is that it points the "small fries" at the hosts you've most likely secured the most. From Firewalls-Owner@GreatCircle.COM Tue Jan 25 01:45:28 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05283; Tue, 25 Jan 94 01:45:28 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05276; Mon, 24 Jan 94 17:45:14 PST Received: from elf.wang.com by tuna.wang.com with SMTP id AA14188 (5.67a/IDA-1.5 for ); Mon, 24 Jan 1994 20:46:57 -0500 Received: by elf.wang.com id AA23713 (5.67a/IDA-1.5); Mon, 24 Jan 1994 20:46:49 -0500 From: Tom Fitzgerald Message-Id: <199401250146.AA23713@elf.wang.com> Subject: Re: schizoprenic dns To: owen@netcom.com Date: Mon, 24 Jan 94 20:46:48 EST Cc: firewalls@greatcircle.com In-Reply-To: <199401250052.QAA04024@asilomar.netcom.com>; from "owen@netcom.com" at Jan 24, 94 4:52 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > - - You can use a wildcard MX, which lets mail be relayed to internal > > systems the moment the system is set up, instead of waiting for the > > zone transfers > > to occur to all the secondaries which need to know about it. (I have > > mixed feelings about this one - if you make a tiny mistake and the > > wildcard MX infects the internal DNS, you're in deep trouble.) > Actually, as long as the wildcard MX doesn't override the internal > information, and the internal information is at a lower number (higher > preference) in it's MX records, it shouldn't affect things too much. The problem with wildcard MXs is that they make operations succeed that SHOULD fail. If your sendmail tries to qualify all addresses in the local domain before resolving them as global addresses, then the wildcard MX will make addresses appear to be internal when they're really external. Suppose the admin of two systems, a.cs.uni.edu and x.chem.uni.edu, wants to let users send mail from each system to the other with the partially- qualified addresses "user@a.cs" or "user@x.chem", without having to specify uni.edu (since they're both in the same parent domain, after all). He sets up sendmail to resolve mailing addresses concatenated with parts of the local domain, and use anything that finds a match in the DNS. If the concatenation fails, then it looks up the address as a global address, i.e. "a.cs" would be resolved as a site in Czechoslovakia. But if an MX for "*.uni.edu" infects those systems, then mail to "user@dec.com" will be successfully resolved as "dec.com.uni.edu", and the mail will almost certainly wind up in a routing loop or bounced with "I refuse to talk to myself." People who remember the "*.edu.com" fiasco of last year (?) can describe the damage a lot more vividly. Unfortunately, using a lower preference for the wildcard doesn't help this; what helps is a lot of careful work in the sendmail source and sendmail.cf (plus abandoning the use of partially-qualified mail addresses). This work hasn't been done on most vendor-distributed sendmails, so unless you've replaced everything with IDA or sendmail8, wildcard MXs can really tie your mailers in knots. -- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA From Firewalls-Owner@GreatCircle.COM Tue Jan 25 03:00:14 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05918; Tue, 25 Jan 94 03:00:14 GMT Received: from mail.uunet.ca (uunet.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05882; Mon, 24 Jan 94 19:00:01 PST Received: from jtsv16 by mail.uunet.ca with UUCP id <128878(2)>; Fri, 21 Jan 1994 18:49:16 -0500 Received: by jts.com (/\==/\ Smail3.1.25.1 #25.17) id ; Fri, 21 Jan 94 12:15 EST Received: by lemon.jts.com (4.1/SMI-4.1) id AA25959; Fri, 21 Jan 94 12:15:17 EST From: jimc@jts.com Message-Id: <9401211715.AA25959@lemon.jts.com> Subject: Re: Pings... To: gil@checkpoint.brm.co.il (Gil Shwed) Date: Fri, 21 Jan 1994 12:15:16 -0500 Cc: firewalls@GreatCircle.COM In-Reply-To: <9401211203.AA02162@checkpoint.brm.co.il> from "Gil Shwed" at Jan 21, 94 02:03:42 pm Reply-To: jimc@jts.com Organization: JTS Computer Systems Ltd., Toronto, Canada X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2062 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Quoting Gil Shwed: + + (1) RPC services are on anonymous ports (they are *not* pre-determined), + the portmapper (sunrpc, port 111) is used only for the + program-number -> port-number mapping. Scanning is very easy since RPC + services usually find themselves on ports just over 1023. RPC/YP scanners + like these were used by Internet intruders, and had very successfull + results... Apologies for making any silly assumptions, but hopefully I'll learn something here. (After all, this is a forum for learning, isn't it? :-) For starters, please clarify whether RPC uses TCP, UDP, or both. This is what I understand: - Inbound TCP >1023 can be filtered (e.g., on a Cisco) by setting the "established" flag; - FTP has a problem with this, due to the passive open from the server's port 20 to some port >1023 on the client; - Inbound UDP >1023 can be filtered, but then how do certain UDP services (DNS springs to mind) get allowed to "complete the call"? Or, is this strictly a feature of TCP? - TCP/UDP port usage >1023 cannot be predetermined, i.e., you cannot force them to use a predetermined range, such as >4096, or? If RPC services "usually find themselves on ports just over 1023", then is there a potential conflict between what you need to deny, and what you need to allow? That is, can I deny TCP/UDP service up to, say, port 1060 to protect the RPC side, but not prevent legitimate outbound connections from being completed? + (2) Though NFS is RPC service, it uses port 2049 on standard systems. Thanks for this one. I was wondering about that. That hole is now plugged. Also, is there a list of "vunerable" ports >1023 (other than this one) that one should be paranoid about? (I hate asking this, as I realize that there will be some concern about giving potential crackers a shopping list....) + + -- Gil Shwed + -- CheckPoint Software Technologies + -- Jim Carroll | JTS Computer Systems Ltd. | The ongoing struggle of jimc@jts.com | Toronto, Ontario | Prometheus vs. Epimetheus.... From Firewalls-Owner@GreatCircle.COM Tue Jan 25 17:44:41 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00443; Tue, 25 Jan 94 17:44:41 GMT Received: from mail.uunet.ca (uunet.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00428; Tue, 25 Jan 94 09:44:24 PST Received: from elegant by mail.uunet.ca with UUCP id <69621(5)>; Mon, 24 Jan 1994 18:05:47 -0500 Received: by elegant (Smail3.1.28.1 #2) id m0pOWdI-0004nYC; Mon, 24 Jan 94 14:07 EST Message-Id: From: jmm@Elegant.COM (John Macdonald) Date: Mon, 24 Jan 1994 14:07:32 -0500 Newsgroups: mail.firewalls In-Reply-To: <199401200724.AA00688@elf.wang.com> Organization: Elegant Communications Inc. X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: firewalls@GreatCircle.COM Subject: Re: double reverse lookup Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In article <199401200724.AA00688@elf.wang.com> fitz@wang.com writes: |I'm certainly no expert... but for people with opaque firewalls (i.e. IP |connectivity to only a few systems, with application gateways for all |services provided across the firewall), split DNS can be worthwhile. This is somewhat off-topic for firewalls, but I suspect for it to be usefully enacted would require significant participation by firewalls participants, so ... It strikes me that using a split DNS and firewall with proxy services results in a setup that could ease the upcoming problem of the Internet running out of addresses. Suppose there were three reserved addresses, one each of type A, B, and C. These addresses would be illegal for use on any inter-organization connection. Then, most organizations could use these network addresses for all of their internal operations and simply request a type C for their external gateway machines. As long as all external interaction was done through proxy services from the gateway, then the only organizations that would need a type A or B address would be those with many gateways, or those that would/could not set up such a proxy service. -- That is 27 years ago, or about half an eternity in | John Macdonald computer years. - Alan Tibbetts | jmm@Elegant.COM From Firewalls-Owner@GreatCircle.COM Tue Jan 25 20:48:09 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01212; Tue, 25 Jan 94 20:48:09 GMT Received: from tin.monsanto.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01205; Tue, 25 Jan 94 12:48:00 PST Received: by tin.monsanto.com (5.57/Monsanto1.3) id AA11591; Tue, 25 Jan 94 14:49:49 -0600 Received: by nicsn1.monsanto.com (4.1/SMI-4.1) id AA01515; Tue, 25 Jan 94 14:49:40 CST From: mwblas@nicsn1.monsanto.com (Marc W. Blaskie) Message-Id: <9401252049.AA01515@nicsn1.monsanto.com> Subject: TALK - any known problems with allowing access from the outside To: Firewalls@greatcircle.com Date: Tue, 25 Jan 94 14:49:39 CST Cc: mwblas@nicsn1.monsanto.com (Marc W. Blaskie) X-Mailer: ELM [version 2.3 PL12] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Currently, we have TALK blocked, but I have a user who needs/wants to be able to use talk to communicate with a collegue outside of our network. Any big problems with allowing this access? Marc Blaskie From Firewalls-Owner@GreatCircle.COM Wed Jan 26 04:07:42 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03717; Wed, 26 Jan 94 04:07:42 GMT Received: from nic.near.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03710; Tue, 25 Jan 94 20:07:34 PST Message-Id: <9401260407.AA03710@mycroft.GreatCircle.COM> Received: from nic.near.net by nic.near.net id aa01367; 25 Jan 94 23:09 EST To: John Macdonald Cc: firewalls@greatcircle.com Subject: Re: double reverse lookup In-Reply-To: Your message of Mon, 24 Jan 1994 14:07:32 -0500. Date: Tue, 25 Jan 1994 23:09:22 -0500 From: John Curran Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk -------- ] From: John Macdonald ] Subject: Re: double reverse lookup ] Date: Mon, 24 Jan 1994 14:07:32 -0500 ] ... ] It strikes me that using a split DNS and firewall with proxy ] services results in a setup that could ease the upcoming ] problem of the Internet running out of addresses. ] ] Suppose there were three reserved addresses, one each of type ] A, B, and C. These addresses would be illegal for use on ] any inter-organization connection. Then, most organizations ] could use these network addresses for all of their internal ] operations and simply request a type C for their external ] gateway machines. As long as all external interaction was ] done through proxy services from the gateway, then the only ] organizations that would need a type A or B address would be ] those with many gateways, or those that would/could not set ] up such a proxy service. This is actively being discussed in the IP Next Generation (IPng) area of the IETF. I expect that we'll see some form of "reserved for local use" address space in the near future, both for the proxy use described above _and_ for organizations that are certain that they'll never connect to the Internet... (Of course, I've seen several such organizations subsequently change their mind, and that's a strong argument against "local use" addresses) Also, it would not be necessary to reserve more than one local-use network, as folks could always use less than the entire reserved space via subnetting. /John From Firewalls-Owner@GreatCircle.COM Wed Jan 26 04:42:03 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03815; Wed, 26 Jan 94 04:42:03 GMT Received: from brazos.is.rice.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03808; Tue, 25 Jan 94 20:41:55 PST Received: by brazos.is.rice.edu (AA19305); Tue, 25 Jan 94 22:43:12 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9401260443.AA19305@brazos.is.rice.edu> Subject: Your A B C's To: jmm@elegant.com (John Macdonald) Date: Tue, 25 Jan 1994 22:43:12 -0600 (CST) Cc: firewalls@greatcircle.com In-Reply-To: from "John Macdonald" at Jan 24, 94 02:07:32 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 629 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk John Macdonald > > Suppose there were three reserved addresses, one each of type > A, B, and C. These addresses would be illegal for use on > any inter-organization connection. Then, most organizations Two already exist.... 127.0.0.0 192.0.2.0 Surely you have seen the old chestnut wrt ftp from 127.0.0.1. Sad. No network provider worth its salt will either source or sink any routes to these nets. ('Course 127 has a -lot- of historical baggage.) -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From Firewalls-Owner@GreatCircle.COM Wed Jan 26 06:12:02 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04037; Wed, 26 Jan 94 06:12:02 GMT Received: from transfer.stratus.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04030; Tue, 25 Jan 94 22:11:52 PST Received: from swdc.stratus.com (stratus.swdc.stratus.com [134.111.20.37]) by transfer.stratus.com (8.6.5/8.6.5) with SMTP id BAA10409; Wed, 26 Jan 1994 01:13:10 -0500 Received: by swdc.stratus.com (4.1/SMI-4.1.10) id AA24797; Tue, 25 Jan 94 22:13:10 PST Date: Tue, 25 Jan 94 22:13:10 PST Message-Id: <9401260613.AA24797@swdc.stratus.com> From: aegl@stratus.swdc.stratus.com To: mwblas@nicsn1.monsanto.com (Marc W. Blaskie), Firewalls@GreatCircle.COM Subject: Re: TALK - any known problems with allowing access from the outside Content-Length: 89 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Yes if your terminals will do exciting things when sent certain escape sequences. -Tony From Firewalls-Owner@GreatCircle.COM Wed Jan 26 07:43:16 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04457; Wed, 26 Jan 94 07:43:16 GMT Received: from mail.uunet.ca (uunet.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04449; Tue, 25 Jan 94 23:43:05 PST Received: from jtsv16 by mail.uunet.ca with UUCP id <59265(9)>; Wed, 26 Jan 1994 01:50:42 -0500 Received: by jts.com (/\==/\ Smail3.1.25.1 #25.17) id ; Tue, 25 Jan 94 09:19 EST Received: by lemon.jts.com (4.1/SMI-4.1) id AA02097; Tue, 25 Jan 94 09:19:18 EST From: jimc@jts.com Message-Id: <9401251419.AA02097@lemon.jts.com> Subject: Re: Pings... To: Marc.Rinfret@eng.canadair.ca (Marc P. Rinfret) Date: Tue, 25 Jan 1994 09:19:17 -0500 Cc: firewalls@greatcircle.com In-Reply-To: <9401250349.AA19271@moosehead.eng.canadair.ca> from "Marc P. Rinfret" at Jan 24, 94 10:49:56 pm Reply-To: jimc@jts.com Organization: JTS Computer Systems Ltd., Toronto, Canada X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3615 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Quoting Marc P. Rinfret: + + > - Inbound UDP >1023 can be filtered, but then how do certain UDP services + > (DNS springs to mind) get allowed to "complete the call"? Or, is this + > strictly a feature of TCP? + + If you want your DNS to be accessible you have to allow UDP traffic on port 53. Ah - that's fine for the destination port. But if my system wants to reply, it replies on *what* port? As far as I know, this cannot be predetermined, except to say that it will be >1023. But how much greater than 1023? Will it be 1024? 1070? 4096? If I deny all outbound UDP ports >1023, then (as far as I know), it's irrelevant that you're allowing inbound connectivity to UDP port 53. Since I'm not likely to block outbound UDP >1023 (except perhaps to thwart any UDP inbound connection from "completing the call"), then let's look at the reverse scenario: I need to enable outbound on UDP port 53. This means that I need to enable inbound on UDP >1023. Wide open. + > - TCP/UDP port usage >1023 cannot be predetermined, i.e., you cannot + > force them to use a predetermined range, such as >4096, or? + Not really, you control the ports on your system allowing traffic corresponding + to the services you offer. You cannot control the source port on the + other end. That's what I thought. + > If RPC services "usually find themselves on ports just over 1023", then + > is there a potential conflict between what you need to deny, and what + > you need to allow? That is, can I deny TCP/UDP service up to, say, + > port 1060 to protect the RPC side, but not prevent legitimate outbound + > connections from being completed? + + You cannot block entirely 1-1060 and expect much to work. That's what I thought. + > + (2) Though NFS is RPC service, it uses port 2049 on standard systems. + > + > Thanks for this one. I was wondering about that. That hole is now plugged. + > + > Also, is there a list of "vunerable" ports >1023 (other than this one) that + > one should be paranoid about? (I hate asking this, as I realize that there + > will be some concern about giving potential crackers a shopping list....) + + I personnally am of the other school of thought. I believe that you + block any port you don't absolutely need. Again, that works great for ports <=1023, but >1023 becomes a problem, as I've already illustrated. + Anyway if you feel you'd rather only plug the worst problems (and + don't worry every cracker or cracker-wannabe already knows this) you + should worry about ports 6000-(6000+n), these ports are used by X + window (n correspond to the number of displays on the station). I believe I've already blocked port 6000. I'll have to check out 6000+n, though. However, and I really have to emphasize this, how do you know that there won't be a conflict of what you want to allow and what you want to deny? I mean, it's my understanding that source port numbers start from 1024 and work their way upwards with each new request. (I really don't know what algorithm is used to reuse these ports.) Although an unlikely scenario, what happens if you're blocking port 6000, and a system suddenly tries to specify TCP port 6000 as it's source port? Or is there a mechanism within IP to say, "hey, that port is reserved for X. Let's use another one." To extend this further, what if I want to block ports >=5000? Can I expect no conflicts with source ports? What about >=4000? >=3000? Etc.? + + Marc. + -- Jim Carroll | JTS Computer Systems Ltd. | The ongoing struggle of jimc@jts.com | Toronto, Ontario | Prometheus vs. Epimetheus.... From Firewalls-Owner@GreatCircle.COM Wed Jan 26 09:26:57 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04715; Wed, 26 Jan 94 09:26:57 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04707; Wed, 26 Jan 94 01:26:50 PST Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA05067; Wed, 26 Jan 94 01:28:14 PST Received: from UK.Sun.COM (sunuk) by snail.Sun.COM (4.1/SMI-4.1) id AA12486; Wed, 26 Jan 94 01:28:10 PST Received: from watchsun.UK.Sun.COM by UK.Sun.COM (4.1/SMI-4.1e-UK) id AA04981; Wed, 26 Jan 94 09:28:08 GMT Received: from zen.UK.Sun.COM by watchsun.UK.Sun.COM (4.1/SMI-5.0-sec(uk - sec)) id AA12619; Wed, 26 Jan 94 09:28:07 GMT Received: by zen.UK.Sun.COM (4.1/SMI-4.0) id AA07221; Wed, 26 Jan 94 09:28:06 GMT Date: Wed, 26 Jan 94 09:28:06 GMT From: Sean.Bennett@UK.Sun.COM (Sean Bennett - Sun UK - CS Hotline Engineer) Message-Id: <9401260928.AA07221@zen.UK.Sun.COM> To: Firewalls@GreatCircle.COM, mwblas@nicsn1.monsanto.com Subject: Re: TALK - any known problems with allowing access from the outside Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk {} {} Currently, we have TALK blocked, but I have a user who needs/wants {} to be able to use talk to communicate with a collegue outside {} of our network. Any big problems with allowing this access? {} If someone wants to be a pain they can send username field that holds control codes that act on xterms to segv them (X11R5) and find out that root/firewall/etc. is not logged in. A possibly better soloution is irc - that way your machines still hide behined a fire wall but the server processes on your gateway machine passes the application specific packets - also the Client to Client protocol (the only real danger with irc) is blocked by your existing firewall. IRC is PD with source available. From Firewalls-Owner@GreatCircle.COM Wed Jan 26 11:13:56 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05285; Wed, 26 Jan 94 11:13:56 GMT Received: from gossip.pyramid.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05278; Wed, 26 Jan 94 03:13:48 PST Received: from slipknot.eng.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA20875; Wed, 26 Jan 94 03:15:37 -0800 Received: by slipknot.eng.pyramid.com (5.61/Pyramid_Internal_Configuration) id AA23342; Wed, 26 Jan 94 03:13:49 -0800 Message-Id: <9401261113.AA23342@slipknot.eng.pyramid.com> Subject: Re: TALK - any known problems with allowing access from the outside To: Firewalls@GreatCircle.COM Date: Wed, 26 Jan 1994 03:13:49 -0800 (PST) In-Reply-To: <9401260928.AA07221@zen.UK.Sun.COM> from "Sean Bennett - Sun UK - CS Hotline Engineer" at Jan 26, 94 09:28:06 am From: pc@pyramid.com Reply-To: pc@pyramid.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1368 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >{} Currently, we have TALK blocked, but I have a user who needs/wants >{} to be able to use talk to communicate with a collegue outside >{} of our network. Any big problems with allowing this access? >{} > >If someone wants to be a pain they can send username field that holds >control codes that act on xterms to segv them (X11R5) and find out that >root/firewall/etc. is not logged in. > >A possibly better soloution is irc - that way your machines still hide behined >a fire wall but the server processes on your gateway machine passes the >application specific packets - also the Client to Client protocol (the only >real danger with irc) is blocked by your existing firewall. IRC is PD with >source available. What is so dangerous about CTCP? Other than bugs which allow people to cause your client to crash, I am not aware of anything especially dangerous about it. The real danger is /exec, which has nothing to do with CTCP. /exec can allow other users on IRC to remotely access a shell on your system. Either disable /exec or make sure your users know the dangers. pc -- -m--------- Patrick Connor Pyramid Technology ---mmm------- (408) 428-8819 3860 North 1st St. -----mmmmm----- pc@pyramid.com -or- San Jose, CA -------mmmmmmm--- uunet!pyramid!pc 95134 From Firewalls-Owner@GreatCircle.COM Wed Jan 26 12:44:08 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05696; Wed, 26 Jan 94 12:44:08 GMT Received: from mwunix.mitre.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05689; Wed, 26 Jan 94 04:44:00 PST Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA23357; Wed, 26 Jan 1994 07:45:23 -0500 Received: from [128.29.140.115] (karndt-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA27346; Wed, 26 Jan 94 07:44:11 EST Date: Wed, 26 Jan 94 07:44:10 EST Message-Id: <9401261244.AA27346@smiley.mitre.org.sit> To: Firewalls@GreatCircle.COM From: karndt@smiley.mitre.org Subject: Re: TALK - any known problems with allowing access from the outside Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Tony, Can you provide an example of such an escape sequence? I know of none that will affect the Talk recipient's terminal when sent as part of a conversation. If, on the other hand, you are referring to sending escape sequences to the recipient's /dev/ttyxx file (or changing the tty settings), yes, that can have interesting results - not the least of which is the ability to log off another user - but I know of no way this can be done by a Talk conversant on another host, only one on the same host as the Talk recipient. Incidentally, the security problem of one user modifying another user's tty file exists not just for the duration of a Talk session, but usually for the entire time the user is logged on (because "mesg y" is the default on most systems, setting the permission bits of the users' tty files to allow write). One Talk feature (?) that does concern me is that if user A on host X initiates a Talk session with user B on host Y, anyone with the same ID as user B on any other host that can access host X will be able to complete the Talk session connection with user A on host X. Worse than that, the only message that user A on host X gets is that the Talk connection has been established. He is not informed that he is talking to user B on host BAD_HOST. (One caveat. User B on host BAD_HOST would have to be monitoring the network traffic to know when user A on host X was attempting to Talk to user B on host Y.) Kate >Yes if your terminals will do exciting things when sent certain escape >sequences. > >-Tony Kate Arndt G023, Secure Information Technology, Mail Stop Z231, The MITRE Corporation, 7525 Colshire Drive McLean, VA 22102-3481 E-mail: karndt@mitre.org Phone: (703) 883-6821 FAX: (703) 883-1397 From Firewalls-Owner@GreatCircle.COM Wed Jan 26 13:38:07 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05870; Wed, 26 Jan 94 13:38:07 GMT Received: from bernina.ethz.ch (bernina-ether.ethz.ch) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05863; Wed, 26 Jan 94 05:37:59 PST Received: from panoramix.ethz.ch by bernina.ethz.ch with SMTP inbound; Wed, 26 Jan 1994 14:39:41 +0100 Received: from localhost (saouli@localhost) by panoramix.ethz.ch (8.6.4/8.6.5.foo.bar) id OAA14914; Wed, 26 Jan 1994 14:38:19 +0100 From: saouli Message-Id: <199401261338.OAA14914@panoramix.ethz.ch> Subject: Re: TALK - any known problems with allowing access from the outside To: karndt@smiley.mitre.org Date: Wed, 26 Jan 1994 14:38:19 +0100 (MET) Cc: Firewalls@GreatCircle.COM In-Reply-To: <9401261244.AA27346@smiley.mitre.org.sit> from "karndt@smiley.mitre.org" at Jan 26, 94 07:44:10 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=LATIN-1 Content-Transfer-Encoding: 8bit Content-Length: 1705 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello, Well what Kate said is true, unless you do a talk that is adressed to a specific tty, but then again the problem is still the same. The other problem is coming from the fact that some network providers are blocking every ports below 1000 arguing that it was dangerous to let them be used. It went even up to the fact that there were no more smtp routing inside a whole country for a while, and everything was routed via X.400. I guess that a right balance between the fully free access of the net and this ultra restrictiv behaviour can be in some ways found. I guess that IRC is definitly the best solution, simply put a leaf server on one of the firewall hosts, make it of a restrictated access, and let your users connect to it. The only tiny problem is the network bandwith used by such an application. Here is an sample of id description on irc: *** ksa is saouli@panoramix.ethz.ch (Karim Saouli) *** on channels: @#eu-opers *** on irc via server irc.ethz.ch (Swiss Fed Inst of Tech of Zurich) *** ksa is an IRC Operator *** ksa has been idle 10 minutes Since it is using the auth protocol, we can consider it a pretty good way to recognise who is talking to you. For the exec problem of irc, well I guess that this can be solved by simply doing that: *** Current value of SHELL is /bin/sh (command set shell under ircII client) For ctcp, well they can be ignored too. So I don't see where the problem is. Regards, K. Saouli -- Karim Saouli Math Department of the System administrator Swiss Fed. Inst. of Tech (ETHZ) Room: HG G 14.2 S-Mail: HG G 14.2 Email: saouli@math.ethz.ch ETH Zentrum Phone: ++41-1-632-2230 CH-8092 Zurich FAX : ++41-1-252-3401 From Firewalls-Owner@GreatCircle.COM Wed Jan 26 05:56:51 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05837; Wed, 26 Jan 94 13:32:54 GMT Received: from email (email.meto.govt.uk) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05830; Wed, 26 Jan 94 05:32:41 PST Received: from email.meto.govt.uk (HANNAVYM@MEADOW) by email.meto.govt.uk (PMDF V4.2-11 #3313) id <01H85244L2B40002AI@email.meto.govt.uk>; Wed, 26 Jan 1994 13:34:01 GMT Date: Wed, 26 Jan 1994 13:34:01 +0000 (GMT) From: HANNAVYM%MEADOW@email.meto.govt.uk To: Firewalls@GreatCircle.COM Message-Id: <01H85244M4W20002AI@email.meto.govt.uk> X-Vms-To: EMAIL::IN%"Firewalls@GreatCircle.COM" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From: EMAIL::IN%"karndt@smiley.mitre.org" 26-JAN-1994 13:22:32.56 To: IN%"Firewalls@GreatCircle.COM" CC: Subj: RE: TALK - any known problems with allowing access from the outside Return-path: Received: from relay1.UU.NET by email.meto.govt.uk (PMDF V4.2-11 #3313) id <01H851KIHK5S0002MA@email.meto.govt.uk>; Wed, 26 Jan 1994 13:18:58 GMT Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwanc27229; Wed, 26 Jan 94 08:12:01 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05696; Wed, 26 Jan 94 12:44:08 GMT Received: from mwunix.mitre.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05689; Wed, 26 Jan 94 04:44:00 PST Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA23357; Wed, 26 Jan 1994 07:45:23 -0500 Received: from [128.29.140.115] (karndt-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA27346; Wed, 26 Jan 94 07:44:11 EST Date: Wed, 26 Jan 1994 07:44:10 -0500 (EST) From: karndt@smiley.mitre.org Subject: RE: TALK - any known problems with allowing access from the outside Sender: Firewalls-Owner@GreatCircle.COM To: Firewalls@GreatCircle.COM Message-id: <9401261244.AA27346@smiley.mitre.org.sit> Content-transfer-encoding: 7BIT Precedence: bulk Tony, Can you provide an example of such an escape sequence? I know of none that will affect the Talk recipient's terminal when sent as part of a conversation. If, on the other hand, you are referring to sending escape sequences to the recipient's /dev/ttyxx file (or changing the tty settings), yes, that can have interesting results - not the least of which is the ability to log off another user - but I know of no way this can be done by a Talk conversant on another host, only one on the same host as the Talk recipient. Incidentally, the security problem of one user modifying another user's tty file exists not just for the duration of a Talk session, but usually for the entire time the user is logged on (because "mesg y" is the default on most systems, setting the permission bits of the users' tty files to allow write). One Talk feature (?) that does concern me is that if user A on host X initiates a Talk session with user B on host Y, anyone with the same ID as user B on any other host that can access host X will be able to complete the Talk session connection with user A on host X. Worse than that, the only message that user A on host X gets is that the Talk connection has been established. He is not informed that he is talking to user B on host BAD_HOST. (One caveat. User B on host BAD_HOST would have to be monitoring the network traffic to know when user A on host X was attempting to Talk to user B on host Y.) Kate >Yes if your terminals will do exciting things when sent certain escape >sequences. > >-Tony Kate Arndt G023, Secure Information Technology, Mail Stop Z231, The MITRE Corporation, 7525 Colshire Drive McLean, VA 22102-3481 E-mail: karndt@mitre.org Phone: (703) 883-6821 FAX: (703) 883-1397 From Firewalls-Owner@GreatCircle.COM Wed Jan 26 06:26:51 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05845; Wed, 26 Jan 94 13:33:28 GMT Received: from email (email.meto.govt.uk) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05838; Wed, 26 Jan 94 05:33:09 PST Received: from email.meto.govt.uk (HANNAVYM@MEADOW) by email.meto.govt.uk (PMDF V4.2-11 #3313) id <01H8524GU22O0002AI@email.meto.govt.uk>; Wed, 26 Jan 1994 13:34:17 GMT Date: Wed, 26 Jan 1994 13:34:17 +0000 (GMT) From: HANNAVYM%MEADOW@email.meto.govt.uk To: Firewalls@GreatCircle.COM Message-Id: <01H8524GUV0I0002AI@email.meto.govt.uk> X-Vms-To: EMAIL::IN%"Firewalls@GreatCircle.COM" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From: EMAIL::IN%"karndt@smiley.mitre.org" 26-JAN-1994 13:22:32.56 To: IN%"Firewalls@GreatCircle.COM" CC: Subj: RE: TALK - any known problems with allowing access from the outside Return-path: Received: from relay1.UU.NET by email.meto.govt.uk (PMDF V4.2-11 #3313) id <01H851KIHK5S0002MA@email.meto.govt.uk>; Wed, 26 Jan 1994 13:18:58 GMT Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwanc27229; Wed, 26 Jan 94 08:12:01 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05696; Wed, 26 Jan 94 12:44:08 GMT Received: from mwunix.mitre.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05689; Wed, 26 Jan 94 04:44:00 PST Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA23357; Wed, 26 Jan 1994 07:45:23 -0500 Received: from [128.29.140.115] (karndt-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA27346; Wed, 26 Jan 94 07:44:11 EST Date: Wed, 26 Jan 1994 07:44:10 -0500 (EST) From: karndt@smiley.mitre.org Subject: RE: TALK - any known problems with allowing access from the outside Sender: Firewalls-Owner@GreatCircle.COM To: Firewalls@GreatCircle.COM Message-id: <9401261244.AA27346@smiley.mitre.org.sit> Content-transfer-encoding: 7BIT Precedence: bulk Tony, Can you provide an example of such an escape sequence? I know of none that will affect the Talk recipient's terminal when sent as part of a conversation. If, on the other hand, you are referring to sending escape sequences to the recipient's /dev/ttyxx file (or changing the tty settings), yes, that can have interesting results - not the least of which is the ability to log off another user - but I know of no way this can be done by a Talk conversant on another host, only one on the same host as the Talk recipient. Incidentally, the security problem of one user modifying another user's tty file exists not just for the duration of a Talk session, but usually for the entire time the user is logged on (because "mesg y" is the default on most systems, setting the permission bits of the users' tty files to allow write). One Talk feature (?) that does concern me is that if user A on host X initiates a Talk session with user B on host Y, anyone with the same ID as user B on any other host that can access host X will be able to complete the Talk session connection with user A on host X. Worse than that, the only message that user A on host X gets is that the Talk connection has been established. He is not informed that he is talking to user B on host BAD_HOST. (One caveat. User B on host BAD_HOST would have to be monitoring the network traffic to know when user A on host X was attempting to Talk to user B on host Y.) Kate >Yes if your terminals will do exciting things when sent certain escape >sequences. > >-Tony Kate Arndt G023, Secure Information Technology, Mail Stop Z231, The MITRE Corporation, 7525 Colshire Drive McLean, VA 22102-3481 E-mail: karndt@mitre.org Phone: (703) 883-6821 FAX: (703) 883-1397 From Firewalls-Owner@GreatCircle.COM Wed Jan 26 14:28:16 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05966; Wed, 26 Jan 94 14:28:16 GMT Received: from callisto.eci-esyst.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05959; Wed, 26 Jan 94 06:28:06 PST Received: from xserve1.ESYSTEMS ([191.254.220.6]) by callisto.eci-esyst.com (4.1/SMI-4.1) id AA06622; Wed, 26 Jan 94 09:26:04 EST Date: Wed, 26 Jan 94 09:26:04 EST From: sdeb@callisto.eci-esyst.com (Steve Eason) Message-Id: <9401261426.AA06622@callisto.eci-esyst.com> To: firewalls@GreatCircle.COM Subject: Firewall Setup for Internet Access Cc: admin@callisto.eci-esyst.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In article <199401200724.AA00688@elf.wang.com> fitz@wang.com writes: |I'm certainly no expert... but for people with opaque firewalls (i.e. IP |connectivity to only a few systems, with application gateways for all |services provided across the firewall), split DNS can be worthwhile. In a recent article, jmm@Elegant.COM (John Macdonald) wrote: ||I'm certainly no expert... but for people with opaque firewalls (i.e. IP ||connectivity to only a few systems, with application gateways for all ||services provided across the firewall), split DNS can be worthwhile. |This is somewhat off-topic for firewalls, but I suspect for it |to be usefully enacted would require significant participation |by firewalls participants, so ... |It strikes me that using a split DNS and firewall with proxy |services results in a setup that could ease the upcoming |problem of the Internet running out of addresses. |Suppose there were three reserved addresses, one each of type |A, B, and C. These addresses would be illegal for use on |any inter-organization connection. Then, most organizations |could use these network addresses for all of their internal |operations and simply request a type C for their external |gateway machines. As long as all external interaction was |done through proxy services from the gateway, then the only |organizations that would need a type A or B address would be |those with many gateways, or those that would/could not set |up such a proxy service. ============================================================== I am relatively new to the Internet world (been connected 4 or 5 months), therefore, I am groping to understand the ways in which a connection can be made secure (without unplugging the firewall or spending years to implement). I have the following questions: The above article mentions: "As long as all external interaction was done through proxy services...". (1) Does this include mail as well as ftp, telnet, etc.? (2) Is there an easy description of how a proxy service works, and how to set one up? Or can someone reference a book(s) or article(s) on this subject? Other related questions: (3) If one had a setup as you describe above, did not wish to have transparent telnet or ftp capabilities from the internal net, and did not have an internal DNS server (the firewall being running DNS), would there be a security hole to have your firewall act as a mailhost? I suppose that this would mean that the internal net machines would all NFS mount the mail spool area from the firewall machine. Thank you for help. S.D.Eason, Engineer E-Systems, ECI Division St. Pete, Florida sdeb@callisto.eci-esyst.com From Firewalls-Owner@GreatCircle.COM Wed Jan 26 14:44:44 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06020; Wed, 26 Jan 94 14:44:44 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06013; Wed, 26 Jan 94 06:44:37 PST Message-Id: <9401261444.AA06013@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Wed Jan 26 09:45:39 EST 1994 To: Firewalls@GreatCircle.COM Subject: Re: TALK - any known problems with allowing access from the outside Date: Wed, 26 Jan 94 09:45:38 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Has anyone ever gone over the code with a fine-toothed comb? I looked at it a few years ago, and though I didn't find any specific holes, I wasn't satisfied with the quality of what I saw. For example, there seemed to be the assumption that some of the fields in the UDP message would be null-terminated, but no check was made (again, this is based on vague recollections). And I don't remember what would happen if someone tried to do a `talk' to `user@../etc/passwd'. From Firewalls-Owner@GreatCircle.COM Wed Jan 26 06:56:51 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05852; Wed, 26 Jan 94 13:33:35 GMT Received: from email (email.meto.govt.uk) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05829; Wed, 26 Jan 94 05:32:27 PST Received: from email.meto.govt.uk (HANNAVYM@MEADOW) by email.meto.govt.uk (PMDF V4.2-11 #3313) id <01H8523QC9NK0002AI@email.meto.govt.uk>; Wed, 26 Jan 1994 13:33:45 GMT Date: Wed, 26 Jan 1994 13:33:45 +0000 (GMT) From: HANNAVYM%MEADOW@email.meto.govt.uk To: Firewalls@GreatCircle.COM Message-Id: <01H8523QF7R60002AI@email.meto.govt.uk> X-Vms-To: EMAIL::IN%"Firewalls@GreatCircle.COM" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From: EMAIL::IN%"karndt@smiley.mitre.org" 26-JAN-1994 13:22:32.56 To: IN%"Firewalls@GreatCircle.COM" CC: Subj: RE: TALK - any known problems with allowing access from the outside Return-path: Received: from relay1.UU.NET by email.meto.govt.uk (PMDF V4.2-11 #3313) id <01H851KIHK5S0002MA@email.meto.govt.uk>; Wed, 26 Jan 1994 13:18:58 GMT Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwanc27229; Wed, 26 Jan 94 08:12:01 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05696; Wed, 26 Jan 94 12:44:08 GMT Received: from mwunix.mitre.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA05689; Wed, 26 Jan 94 04:44:00 PST Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA23357; Wed, 26 Jan 1994 07:45:23 -0500 Received: from [128.29.140.115] (karndt-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA27346; Wed, 26 Jan 94 07:44:11 EST Date: Wed, 26 Jan 1994 07:44:10 -0500 (EST) From: karndt@smiley.mitre.org Subject: RE: TALK - any known problems with allowing access from the outside Sender: Firewalls-Owner@GreatCircle.COM To: Firewalls@GreatCircle.COM Message-id: <9401261244.AA27346@smiley.mitre.org.sit> Content-transfer-encoding: 7BIT Precedence: bulk Tony, Can you provide an example of such an escape sequence? I know of none that will affect the Talk recipient's terminal when sent as part of a conversation. If, on the other hand, you are referring to sending escape sequences to the recipient's /dev/ttyxx file (or changing the tty settings), yes, that can have interesting results - not the least of which is the ability to log off another user - but I know of no way this can be done by a Talk conversant on another host, only one on the same host as the Talk recipient. Incidentally, the security problem of one user modifying another user's tty file exists not just for the duration of a Talk session, but usually for the entire time the user is logged on (because "mesg y" is the default on most systems, setting the permission bits of the users' tty files to allow write). One Talk feature (?) that does concern me is that if user A on host X initiates a Talk session with user B on host Y, anyone with the same ID as user B on any other host that can access host X will be able to complete the Talk session connection with user A on host X. Worse than that, the only message that user A on host X gets is that the Talk connection has been established. He is not informed that he is talking to user B on host BAD_HOST. (One caveat. User B on host BAD_HOST would have to be monitoring the network traffic to know when user A on host X was attempting to Talk to user B on host Y.) Kate >Yes if your terminals will do exciting things when sent certain escape >sequences. > >-Tony Kate Arndt G023, Secure Information Technology, Mail Stop Z231, The MITRE Corporation, 7525 Colshire Drive McLean, VA 22102-3481 E-mail: karndt@mitre.org Phone: (703) 883-6821 FAX: (703) 883-1397 From Firewalls-Owner@GreatCircle.COM Wed Jan 26 16:31:42 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06593; Wed, 26 Jan 94 16:31:42 GMT Received: from uswat.advtech.uswest.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06582; Wed, 26 Jan 94 08:31:25 PST Received: from futureworld.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA19599 (5.67b/IDA-1.5 for ); Wed, 26 Jan 1994 09:32:53 -0700 Received: from localhost.uswest.com by futureworld.advtech.uswest.com (advtech.uswest.com) id AA18222 (4.1/at-generic.8Nov93); Wed, 26 Jan 94 09:32:36 MST Message-Id: <9401261632.AA18222@futureworld.advtech.uswest.com> To: jimc@jts.com Cc: Marc.Rinfret@eng.canadair.ca (Marc P. Rinfret), firewalls@greatcircle.com Subject: Re: Pings... In-Reply-To: Your message of "Tue, 25 Jan 1994 09:19:17 EST." <9401251419.AA02097@lemon.jts.com> Date: Wed, 26 Jan 1994 09:32:35 -0700 From: Brad Huntting Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk + If you want your DNS to be accessible you have to allow UDP traffic + on port 53. > Ah - that's fine for the destination port. But if my system wants to > reply, it replies on *what* port? As far as I know, this cannot be > predetermined, except to say that it will be >1023. But how much greater > than 1023? Will it be 1024? 1070? 4096? If I deny all outbound UDP > ports >1023, then (as far as I know), it's irrelevant that you're allowing > inbound connectivity to UDP port 53. BIND nameservers always talk to each other on port 53 (source and destination). So you just need to point your resolvers at an inside nameserver which can pass UDP port 53 packets to and from the outside. To facilitate human quearies of outside machines use TCP quearies. brad From Firewalls-Owner@GreatCircle.COM Wed Jan 26 16:39:42 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06652; Wed, 26 Jan 94 16:39:42 GMT Received: from BGUVM.BGU.AC.IL by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06645; Wed, 26 Jan 94 08:39:26 PST Received: from ramon.bgu.ac.il by BGUVM.BGU.AC.IL (IBM VM SMTP V2R2) with TCP; Wed, 26 Jan 94 18:40:44 IST Received: by ramon.bgu.ac.il (920330.SGI/920502.SGI.AUTO) for @bguvm.bgu.ac.il:mwblas@nicsn1.monsanto.com id AA05902; Wed, 26 Jan 94 18:36:55 +0200 From: jsz@ramon.bgu.ac.il Message-Id: <9401261636.AA05902@ramon.bgu.ac.il> Subject: Re: TALK - any known problems with allowing access from the outside To: karndt@smiley.mitre.org Date: Wed, 26 Jan 94 18:36:40 IST Cc: firewalls@greatcircle.com, mwblas@nicsn1.monsanto.com In-Reply-To: <9401261244.AA27346@smiley.mitre.org.sit>; from "karndt@smiley.mitre.org" at Jan 26, 94 7:44 am Origanization: The Society for the Propagation of Healthy Sex & Prevention of Pervertness X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Umm. I haven't heard of any SERIOUS security problems with talkd, aside of that in.talkd can be used to destroy any system file, under condition that /etc/utmp is world writeable. Bad boy needs to alter /etc/utmp file, so /dev/ttyX line is replaced with /file/that/he/wants/to/erase, and then talk to the the user with the patched entry in utmp. Then the /file/that/he/wants/to/earse is being truncated. Just thought it'd be related to the discussion. Writeable /etc/utmp is a hole, and anything that trusts /etc/utmp is vulnerable too. ---Jonathan From Firewalls-Owner@GreatCircle.COM Wed Jan 26 16:52:49 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06744; Wed, 26 Jan 94 16:52:49 GMT Received: from mwunix.mitre.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA06734; Wed, 26 Jan 94 08:52:40 PST Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA05593; Wed, 26 Jan 1994 11:54:18 -0500 Received: from [128.29.140.151] (woycke-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA01430; Wed, 26 Jan 94 11:53:07 EST Message-Id: <9401261653.AA01430@smiley.mitre.org.sit> X-Sender: woycke@128.29.140.20 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Jan 1994 12:15:18 -0400 To: mwblas@nicsn1.monsanto.com (Marc W. Blaskie), Firewalls@GreatCircle.COM From: woycke@mitre.org (Daniel W. Woycke) Subject: Re: TALK - any known problems with allowing access from the outside Cc: mwblas@nicsn1.monsanto.com (Marc W. Blaskie) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 2:49 PM 1/25/94 -0600, Marc W. Blaskie wrote: > Currently, we have TALK blocked, but I have a user who needs/wants > to be able to use talk to communicate with a collegue outside > of our network. Any big problems with allowing this access? > > > Marc Blaskie Marc, My personal opinion is that if you allow telnet access through the firewall perhaps giving the "collegue outside" telnet access to the system and let talk run on your local machine. Or you can get the inside user access to the external machine and let them run talk there. There is no authentication mechanism in place for talk (that I know of) so the authentication should be done by telnet. Also, I feel that adding any protocols is not a good idea. ---------- Thank You, Daniel W. Woycke |"It is not that life _is_ an illusion; Information Engineer (c) 1992|rather life is _like_ an illusion." The MITRE Corporation |--The Dalai Lama 7525 Colshire Drive (MS Z231)| McLean, VA 22102 |These opinions are mine and are not phone: (703) 883-1362 |and will not be held by anyone else. From Firewalls-Owner@GreatCircle.COM Wed Jan 26 16:55:54 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08545; Thu, 27 Jan 94 00:43:38 GMT Received: from cs.columbia.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08538; Wed, 26 Jan 94 16:43:26 PST Received: from hudson.cs.columbia.edu (dupuy@hudson.cs.columbia.edu [128.59.25.2]) by cs.columbia.edu (8.6.4/8.6.4) with ESMTP id TAA07247; Wed, 26 Jan 1994 19:44:48 -0500 Received: from localhost (dupuy@localhost) by hudson.cs.columbia.edu (8.6.4/8.6.4) id TAA16084; Wed, 26 Jan 1994 19:44:46 -0500 Date: Wed, 26 Jan 94 19:44:44 EST From: Alexander Dupuy To: smb@research.att.com Reply-To: dupuy@cs.columbia.edu Subject: Re: living with reverse DNS lookups In-Reply-To: Your message of Mon, 17 Jan 94 11:25:32 EST Cc: p-pomes@uiuc.edu, firewalls@greatcircle.com Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Yes and no. The DNS data is a potent source of information for > industrial espionage. It's also useful to hackers for target selection. Of course, things like hostnames already leak out every day (have you looked at the Received: headers on mail?) so it's not clear that DNS is really opening you up that much. The only information that serves no functional purpose and gives crackers useful information is the DNS HINFO data (although similar information is often available in Received: headers as well). Of course, with hostnames like mac1, joes-pc, etc. the HINFO data isn't giving away anything too obvious either. A question - how many people who install separate DNS external and internal servers also modify the MTA on the bastion host to strip out all Received: headers on outgoing mail? I suspect that very few do this. @alex From Firewalls-Owner@GreatCircle.COM Thu Jan 27 06:19:28 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09992; Thu, 27 Jan 94 06:19:28 GMT Received: from shadow.net (anshar.shadow.net) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09985; Wed, 26 Jan 94 22:19:16 PST Received: from localhost (cklaus@localhost) by shadow.net (8.6.4/jc-1.0) id BAA07547; Thu, 27 Jan 1994 01:22:11 -0500 From: Christopher Klaus Message-Id: <199401270622.BAA07547@shadow.net> Subject: Re: living with reverse DNS lookups To: dupuy@cs.columbia.edu Date: Thu, 27 Jan 94 1:22:10 EST Cc: p-pomes@uiuc.edu, firewalls@GreatCircle.COM, smb@research.att.com In-Reply-To: ; from "Alexander Dupuy" at Jan 26, 94 7:44 pm X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > > Yes and no. The DNS data is a potent source of information for > > industrial espionage. It's also useful to hackers for target selection. > > Of course, things like hostnames already leak out every day (have you looked at > the Received: headers on mail?) so it's not clear that DNS is really opening > you up that much. The only information that serves no functional purpose and > gives crackers useful information is the DNS HINFO data (although similar > information is often available in Received: headers as well). Of course, with > hostnames like mac1, joes-pc, etc. the HINFO data isn't giving away anything > too obvious either. > > A question - how many people who install separate DNS external and internal > servers also modify the MTA on the bastion host to strip out all Received: > headers on outgoing mail? I suspect that very few do this. Not to mention all the users that may post on Usenet. The work for hiding hostnames from the outside world really doesnt offer that much more protection. -- Christopher William Klaus Email: cklaus@shadow.net Author:Inet Sec. Scanner 2209 Summit Place Drive,Dunwoody, GA 30350-2430. (404)206-1513. From Firewalls-Owner@GreatCircle.COM Thu Jan 27 06:25:57 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10072; Thu, 27 Jan 94 06:25:57 GMT Received: from shadow.net (anshar.shadow.net) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10054; Wed, 26 Jan 94 22:25:39 PST Received: from localhost (cklaus@localhost) by shadow.net (8.6.4/jc-1.0) id BAA07593; Thu, 27 Jan 1994 01:28:29 -0500 From: Christopher Klaus Message-Id: <199401270628.BAA07593@shadow.net> Subject: Re: TALK - any known problems with allowing access from the outside To: jsz@ramon.bgu.ac.il Date: Thu, 27 Jan 94 1:28:28 EST Cc: firewalls@GreatCircle.COM, mwblas@nicsn1.monsanto.com In-Reply-To: <9401261636.AA05902@ramon.bgu.ac.il>; from "jsz@ramon.bgu.ac.il" at Jan 26, 94 6:36 pm X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > > Umm. I haven't heard of any SERIOUS security problems with talkd, aside of that > in.talkd can be used to destroy any system file, under condition that /etc/utmp > is world writeable. Bad boy needs to alter /etc/utmp file, so /dev/ttyX > line is replaced with /file/that/he/wants/to/erase, and then talk to the > the user with the patched entry in utmp. Then the /file/that/he/wants/to/earse > is being truncated. > > Just thought it'd be related to the discussion. Writeable /etc/utmp is a hole, > and anything that trusts /etc/utmp is vulnerable too. I think the original author wanted to know if there was a security problem using talk with the outside world. Obviously, you cant modify utmp via remotely, if the only thing open is talkd. Most in.talkd's have been patched so that they no longer overwrite files if utmp is modified. The only securrity risk talkd might offer is disruption of service. That is, if someone wrote a program to do like 50 simulationous talkd request to a person, then that person might have trouble doing work, etc. But can easily be fixed by turning off talk requests via mesg n. -- Christopher William Klaus Email: cklaus@shadow.net Author:Inet Sec. Scanner 2209 Summit Place Drive,Dunwoody, GA 30350-2430. (404)206-1513. From Firewalls-Owner@GreatCircle.COM Thu Jan 27 13:11:30 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11527; Thu, 27 Jan 94 13:11:30 GMT Received: from mgc.mentorg.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11520; Thu, 27 Jan 94 05:11:22 PST Received: from warren.mentorg.com by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA07660; Thu, 27 Jan 94 05:13:10 -0800 Received: by Warren.MENTORG.COM id AA25131 (5.65c/IDA-1.4.4 for Firewalls@GreatCircle.COM); Thu, 27 Jan 1994 08:13:08 -0500 To: Firewalls@greatcircle.com Path: not-for-mail From: tom_limoncelli@Warren.MENTORG.COM (Tom Limoncelli) Newsgroups: mentorg.list.firewalls Subject: Re: living with reverse DNS lookups Date: 27 Jan 1994 08:13:07 -0500 Organization: Mentor Graphics -- IC Group, Warren, NJ, USA Lines: 16 Message-Id: <2i8el3$oh8$1@sdl.Warren.MENTORG.COM> References: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In Alexander Dupuy writes: >A question - how many people who install separate DNS external and internal >servers also modify the MTA on the bastion host to strip out all Received: >headers on outgoing mail? I suspect that very few do this. None do because then you lose your only debugging tool for solving mailer problems. Tom -- Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.org (play) "Psst! Hey, Anthony! Y'know what I | Disclaimer: I do not like about existing?" "Uh... uh... what?" | speak for Mentor Graphics. "Possessing a physical extension." -TSA | From Firewalls-Owner@GreatCircle.COM Thu Jan 27 16:26:36 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12528; Thu, 27 Jan 94 16:26:36 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12520; Thu, 27 Jan 94 08:26:29 PST Message-Id: <9401271626.AA12520@mycroft.GreatCircle.COM> To: Firewalls@greatcircle.com Subject: Re: living with reverse DNS lookups In-Reply-To: Your message of 27 Jan 1994 08:13:07 -0500 Date: Thu, 27 Jan 1994 08:26:28 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk tom_limoncelli@Warren.MENTORG.COM (Tom Limoncelli) writes: # In Alexander Dupuy writes: # # >A question - how many people who install separate DNS external and internal # >servers also modify the MTA on the bastion host to strip out all Received: # >headers on outgoing mail? I suspect that very few do this. # # None do because then you lose your only debugging tool for # solving mailer problems. Think of dumpster diving and your company phone list. At most companies, the internal phone list is confidential and not for distribution outside the company; same with hiding host info in DNS. At most companies, someone could go through all your trash dumpsters and eventually come up with most of the info on the phone list; same with collecting host names from mail and news postings. The question isn't whether or not someone sufficiently motivated and bored who's willing to devote enough time and resources to the problem can get the info; clearly they can. The question is, should you make it difficult enough that most people won't bother to invest the time and resources? -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Thu Jan 27 08:29:25 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12402; Thu, 27 Jan 94 16:13:00 GMT Received: from millennium.tw.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12395; Thu, 27 Jan 94 08:12:48 PST Received: by millennium.tw.com (4.1/9999.1) id AA25487; Thu, 27 Jan 94 08:16:06 PST Date: Thu, 27 Jan 94 08:16:06 PST From: wadlow@tw.com (Tom Wadlow) Message-Id: <9401271616.AA25487@tw.com> To: dupuy@cs.columbia.edu Subject: Re: living with reverse DNS lookups Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Date: Wed, 26 Jan 94 19:44:44 EST From: Alexander Dupuy > Yes and no. The DNS data is a potent source of information for > industrial espionage. It's also useful to hackers for target selection. Of course, things like hostnames already leak out every day (have you looked at the Received: headers on mail?) so it's not clear that DNS is really opening you up that much. Sure it does. It makes the information about hostnames *vastly* cheaper to get. If somebody's got to find it by extracting it from mail headers, they've got to do a lot more work to get hostnames (and more still to get IP addresses). If the same information is available via DNS, you're delivering it to them at wholesale prices. --Tom From Firewalls-Owner@GreatCircle.COM Thu Jan 27 09:18:11 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13167; Thu, 27 Jan 94 17:07:14 GMT Received: from srv.cip.physik.tu-muenchen.de by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13133; Thu, 27 Jan 94 09:06:02 PST Received: from comserv.cip.physik.tu-muenchen.de by srv.cip.physik.tu-muenchen.de with SMTP id AA28019 for (5.67a/IDA-1.5/bs03); Thu, 27 Jan 1994 18:05:49 +0100 Message-Id: <199401271705.AA28019@srv.cip.physik.tu-muenchen.de> To: Firewalls@greatcircle.com Subject: Re: TALK - any known problems with allowing access from the outside In-Reply-To: Your message of "Wed, 26 Jan 94 09:28:06 GMT." <9401260928.AA07221@zen.UK.Sun.COM> Date: Thu, 27 Jan 94 18:05:47 +0100 From: Bernhard.Schneck@Physik.TU-Muenchen.DE Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > {} Currently, we have TALK blocked, but I have a user who needs/wants > {} to be able to use talk to communicate with a collegue outside > {} of our network. Any big problems with allowing this access? Anyway, talk uses it's UDP port (517/518) just to tell each side which TCP ports to use, and these are allocated on demand (and thus hard to filter). IRC *might* be better/easier to control (most IRC servers use either TCP/194 or TCP/6667), but beware of the `mail' and `ctc' messages within IRC. From Firewalls-Owner@GreatCircle.COM Thu Jan 27 17:47:33 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13417; Thu, 27 Jan 94 17:47:33 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13410; Thu, 27 Jan 94 09:47:26 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwarn16235; Thu, 27 Jan 94 12:49:08 -0500 Received: from racerx.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 124836.24163; Thu, 27 Jan 1994 12:48:36 EST Received: from bert.noname (ernie) by racerx (4.1/SMI-4.0) id AA00677; Thu, 27 Jan 94 11:27:06 CST Date: Thu, 27 Jan 94 11:27:06 CST From: ken@bridge.COM (Ken Hardy) Message-Id: <9401271727.AA00677@racerx> To: firewalls@greatcircle.com Subject: TIS & SOCKS coexist? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Can the TIS toolkit and SOCKS co-exist on the same firewall? I'm on the verge of installing the TIS toolkit on a dual-homed bastion host. But I just got a look a Mosaic. I like it, and I'm _sure_ that others (higher up) here will _really_ like it. But as far as I'm aware, the only firewall support for it is with SOCKS. So what I'm really after, is a way to run Mosaic through a TIS firewall, I guess, whether it involves SOCKS or not. -Ken From Firewalls-Owner@GreatCircle.COM Thu Jan 27 19:00:19 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13856; Thu, 27 Jan 94 19:00:19 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13849; Thu, 27 Jan 94 11:00:12 PST Received: by relay.tis.com; id AA19023; Thu, 27 Jan 94 14:02:14 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma019017; Thu Jan 27 14:02:05 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA09640; Thu, 27 Jan 94 14:01:35 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA07044; Thu, 27 Jan 94 14:01:33 EST Date: Thu, 27 Jan 94 14:01:33 EST From: mjr@tis.com Message-Id: <9401271901.AA07044@otter.tis.com> To: firewalls@GreatCircle.COM, ken@bridge.COM Subject: Re: TIS & SOCKS coexist? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Can the TIS toolkit and SOCKS co-exist on the same firewall? I'm on >the verge of installing the TIS toolkit on a dual-homed bastion host. Certainly. The goal of the toolkit was to provide very modular components that work alone to provide basic services for a firewall. You should be able to layer anything you like around and on top of the toolkit, as long as you're comfortable with it. For example, the toolkit was intended to work either with a dual-homed firewall approach, or with (perhaps) a router permitting "established" telnet sessions, but requiring FTP to go through the toolkit proxy. Obviously, the only caution with the "mix and match" approach is that it's up to you to verify the security of whatever you add around the toolkit. mjr. From Firewalls-Owner@GreatCircle.COM Thu Jan 27 11:12:30 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13905; Thu, 27 Jan 94 19:04:11 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13896; Thu, 27 Jan 94 11:04:00 PST Received: from elf.wang.com by tuna.wang.com with SMTP id AA08869 (5.67a/IDA-1.5); Thu, 27 Jan 1994 14:05:42 -0500 Received: by elf.wang.com id AA03814 (5.67a/IDA-1.5); Thu, 27 Jan 1994 14:05:35 -0500 From: Tom Fitzgerald Message-Id: <199401271905.AA03814@elf.wang.com> Subject: Re: living with reverse DNS lookups To: brent@greatcircle.com (Brent Chapman) Date: Thu, 27 Jan 94 14:05:31 EST Cc: Firewalls@greatcircle.com In-Reply-To: <9401271626.AA12520@mycroft.GreatCircle.COM>; from "Brent Chapman" at Jan 27, 94 8:26 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > At most companies, the internal phone list is confidential and not for > distribution outside the company; same with hiding host info in DNS. > The question isn't whether or not someone sufficiently motivated and > bored who's willing to devote enough time and resources to the problem > can get the info; clearly they can. The question is, should you make > it difficult enough that most people won't bother to invest the time > and resources? Dumpster diving is manual effort - DNS/mailheader/newsheader scrounging can easily be automated. I doubt it's worth putting any time into a defense when someone can write a piece of software that bypasses it. Only one person needs to invest any effort, and then the tool can be distributed to any number of potential intruders. One of my newsservers is constantly being probed to see if it's an open nntp server [it isn't], I suspect this is from people with a script that does find /usr/spool/news -type f -print | xargs egrep "^Path: " | \ tr ' !' '\012\012' | egrep "\." | open-nntp-port-tester > logfile I don't believe anyone is wasting his/her time trying all these sites by hand (or, if anyone is, that's someone I don't have to worry about anyway). -- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA From Firewalls-Owner@GreatCircle.COM Thu Jan 27 21:25:16 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14550; Thu, 27 Jan 94 21:25:16 GMT Received: from nic.cic.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14543; Thu, 27 Jan 94 13:25:06 PST Received: by nic.cic.net (4.1/2.25) id AA09862; Thu, 27 Jan 94 16:27:02 EST Date: Thu, 27 Jan 1994 16:27:02 -0500 (EST) From: Paul Holbrook Subject: Firewall router hardware for < $2k? To: firewalls@greatcircle.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We get a number of customers connecting to us that to want to have a firewall router. However, we don't let customers touch the router we put on their site; our demarc is on the Ethernet interface on the router we put on their site. (I know that's not the way everyone does it, but we basically decided we couldn't guarantee either the realiabity of their connection or their security if both provider and customer could change the router configuration.) So if they want to do a firewall, we give them some tips, but we basically let them buy a router and do the job themselves. In the past, we've typically recommended that they buy a low-end Cisco. I'm not convinced that's the best recommendation; I believe there are other boxes out there that are both cheaper and also might do a better job or be easier to configure. What kind of hardware is out there that can do a reasonable job of filtering IP traffic that costs less than $2000? (I'm not firm on that number; if something is little more I'm interested.) Remember, we're talking about ethernet-to-ethernet here. I believe that knocks out a few of the low-end routers. I'd be interested in the basics: vendor name/model and approximate cost. I'd also be interested in any comments (pro or con) about any of the boxes. What do you recommend to people? J. Paul Holbrook CICNet Network Services Manager holbrook@cic.net (313) 998-7680 From Firewalls-Owner@GreatCircle.COM Thu Jan 27 22:34:35 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14770; Thu, 27 Jan 94 22:34:35 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14763; Thu, 27 Jan 94 14:34:24 PST Message-Id: <9401272234.AA14763@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu Jan 27 17:30:37 EST 1994 To: firewalls@greatcircle.com Subject: speed of packet-filtering Date: Thu, 27 Jan 94 17:30:36 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The following measurements of the speed of packet-filtering on Cisco routers appeared on another mailing list. It's reposted here with permission. --Steve Bellovin ------- Forwarded Message Date: Thu, 27 Jan 94 13:00:47 EST From: mark@escact.ksc.nasa.gov (Mark Gibbons) Message-Id: <9401271800.AA14211@escact.ksc.nasa.gov.nasa.gov> To: cisco@spot.colorado.edu Subject: Re: Benchmarking of filters. Well, I couldn't get everything I wanted but here is a rough list that indicates the effect of access lists on throughput. We did look at CPU but did not record it, however I don't recall any concern about the % utilization. Test config: Cisco AGS+ CSC/4 running 9.1(2). The AGS had 1 serial & 4 ethernet ports configed to route IP, DEC, Novell & AppleTalk, but we only used single stream IP data. We used a PowerBits ethernet tester to deliver Ip packets to the router & determine throughput rate. The access list was set up so that the last line of the list was the one which would permit the packet (this being the worst case). In Packet Per Second Pkt size Loopback 0 40 80 120 160 200 <--list size 64 14787 13307 9300 7695 6769 5561 4661 128 8418 8224 6537 5583 5157 4486 3851 256 4521 4521 4047 3679 3475 3121 2830 512 2348 2336 2293 2172 2097 1968 1849 768 1585 1577 1585 1541 1504 1435 1372 1024 1196 1192 1191 1196 1173 1130 1090 1280 960 958 958 960 960 932 904 1518 811 811 811 811 811 811 800 List size has little to no effect on large packet streams, however studies show 66% of our traffic is < 128 byte packets (Scott Bradner's numbers tend to show that is not abnormal). I ran this test using CSC/3 CPU with no list & with an 80 entry list & got these numbers: Pkt size 0 80 64 9274 3479 128 6569 3017 256 4241 2410 512 2348 1719 768 1585 1333 1024 1196 1089 1280 960 920 1518 811 805 You can see the CSC/4 is clearly superior in this test. If I get requests for more info I will look for other test files & post, as time permits. If you need info on the PowerBits, or Bradner's work at Harvard just ask. Sorry this is not more complete, me ||| (0 0) - -------------------------------ooO-(_)-Ooo--------------------------------- mark e. gibbons mark@luke.ksc.nasa.gov M.S. INI-18 (v)407.867.4847 mark-gibbons@ksc.nasa.gov Kennedy Space Center, (f)407.867.4079 Florida 32899 As scarce as truth is, the supply has always been in excess of the demand ------- End of Forwarded Message From Firewalls-Owner@GreatCircle.COM Fri Jan 28 01:10:46 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15339; Fri, 28 Jan 94 01:10:46 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15332; Thu, 27 Jan 94 17:10:37 PST Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA15818; Thu, 27 Jan 94 20:12:32 -0500 Date: Thu, 27 Jan 94 20:12:32 -0500 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9401280112.AA15818@bedrock.cs.UMD.EDU> To: firewalls@greatcircle.com Subject: Why, sure. Will UID=0 be OK ? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Here was an interesting request that found its way to my mailbox at work today; has anyone else seen any of these? Richard -- begin included text [ trimmed, etc. ] From REFST8@vms.cis.pitt.edu Thu Jan 27 16:08:51 1994 Return-Path: Received: from mh.site.domain by host.site.domain (4.1/SMI-4.1) id AA06546; Thu, 27 Jan 94 16:08:50 EST Received: from VM2.CIS.PITT.EDU by mh.site.domain (4.1/SMI-4.1) id AA01345; Thu, 27 Jan 94 16:09:02 EST Received: from vms.cis.pitt.edu by vms.cis.pitt.edu (PMDF #12376) id <01H86LKWAFHG9YCVKM@vms.cis.pitt.edu>; Thu, 27 Jan 1994 16:02 EST Date: Thu, 27 Jan 1994 16:02 EST From: "R.E.F." Subject: Inquiry To: reh@site.domain Message-Id: <01H86LKWAFHG9YCVKM@vms.cis.pitt.edu> X-Envelope-To: reh@site.domain X-Vms-To: IN%"reh@site.domain" Content-Length: 1947 X-Lines: 41 Status: RO Dear sirs: Firstly, I would like to thank you for taking the time to read this letter and I ask you to please consider this inquiry. I am writing to you in hope that you may be able to provide some help. Some fellow students and I presently administer a Multi-User Dimension game, or MUD as it is known by its acronym. The main purpose for our initial involvement in setting up the MUD was to apply and improve our knowledge of C. However, as it evolved, it turned into something we did that provided us, as well as the players, with some relaxation from the events of the day. We currently have a site from which the MUD is running on, but as it turns out, the host is located in the United Kingdom. The problem which is presented by this arrangement is the unreliable connection offered by the trans-atlantic links which are currently in place. Which brings me to the purpose of this letter. I am wondering if you would be interested and willing to provide us with an account that would be free of charge from which this particular Interactive venture can be run from. Our requirements for the account are not overbearing. We presently utilize 15 to 20Mb of diskspace, and the demands on the system are minimal; on the system we currently use (i386 running Linux 0.99.14t) they are hardly, if ever, felt. We have a good service record, and as a matter of fact, when the sysadmin at the current site decided to grant permission to administer a MUD at his site, we were chosen over three other ones due to our good behaviour record. I thank you again for taking the time to consider this request and if you should need any additional information relating to this matter in order to make a more informed decision, please do not hesitate to contact me. Waiting for a reply I remain, Sincerely, R. Eric Felix From Firewalls-Owner@GreatCircle.COM Thu Jan 27 18:42:32 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15656; Fri, 28 Jan 94 02:35:12 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15643; Thu, 27 Jan 94 18:34:52 PST Message-Id: <9401280234.AA15643@mycroft.GreatCircle.COM> To: Paul Holbrook Cc: firewalls@greatcircle.com Subject: Re: Firewall router hardware for < $2k? In-Reply-To: Your message of Thu, 27 Jan 1994 16:27:02 -0500 (EST) Date: Thu, 27 Jan 1994 18:34:49 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Paul Holbrook writes: # What kind of hardware is out there that can do a reasonable job of # filtering IP traffic that costs less than $2000? (I'm not firm on that # number; if something is little more I'm interested.) Remember, we're # talking about ethernet-to-ethernet here. I believe that knocks out a few # of the low-end routers. When you say "ethernet-to-ethernet", do you mean it's got to have two Ethernet interfaces, or do you mean that it's got to have Ethernet performance levels? The first is true. The second is true only if their Internet connection is an Ethernet-speed connection, which is fairly rare. Most sites have only 56 Kb/s or, at best, 1.544 Mb/s (T1) links to the Internet. With 64 byte packets (pretty close to practical minimum), 1.544 Mb/s is only 3162 packets per second. 1518 byte packets (maximim packet size) is only 133 packets per second. According to the figures for Ciscos forwarded earlier today by Steve Bellovin, both of those are well within the capabilities of Ciscos with an old CSC/3 CPU card (and that's what, 5-year-old technology?). I'd expect it to similarly be within the capabilities of most current low-end IP routers. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Fri Jan 28 03:46:08 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15947; Fri, 28 Jan 94 03:46:08 GMT Received: from nic.cic.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15940; Thu, 27 Jan 94 19:45:56 PST Received: by nic.cic.net (4.1/2.25) id AA11552; Thu, 27 Jan 94 22:47:21 EST Date: Thu, 27 Jan 1994 22:47:21 -0500 (EST) From: Paul Holbrook Subject: Re: Firewall router hardware for < $2k? To: Brent Chapman Cc: firewalls@greatcircle.com In-Reply-To: <9401280234.AA15643@mycroft.GreatCircle.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Thu, 27 Jan 1994, Brent Chapman wrote: > When you say "ethernet-to-ethernet", do you mean it's got to have two > Ethernet interfaces, or do you mean that it's got to have Ethernet > performance levels? The first is true. I mean the first - two Ethernet interfaces. That's because it sits between our router (which has a serial link on one side and an ethernet on the other) and their internal network. I hadn't considered performance because it really only has to keep up with a maximum of T-1 speeds, which as you note is within the capability of most low-end routers. J. Paul Holbrook CICNet Network Services Manager holbrook@cic.net (313) 998-7680 From Firewalls-Owner@GreatCircle.COM Fri Jan 28 08:03:54 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA17401; Fri, 28 Jan 94 08:03:54 GMT Received: from is.rice.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA17394; Fri, 28 Jan 94 00:03:47 PST Received: by is.rice.edu (AA22311); Fri, 28 Jan 94 02:05:41 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9401280805.AA22311@is.rice.edu> Subject: Re: Firewall router hardware for < $2k? To: holbrook@cic.net (Paul Holbrook) Date: Fri, 28 Jan 1994 02:05:41 -0600 (CST) Cc: firewalls@greatcircle.com In-Reply-To: from "Paul Holbrook" at Jan 27, 94 04:27:02 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 282 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk For the lowend, we like the cisco 2500 series. Comes in under the $2k limit for us and does the job well. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From Firewalls-Owner@GreatCircle.COM Fri Jan 28 13:31:44 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18583; Fri, 28 Jan 94 13:31:44 GMT Received: from ns1.arlut.utexas.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18576; Fri, 28 Jan 94 05:31:37 PST Received: from localhost (pug@localhost) by ns1.arlut.utexas.edu (8.6.4/8.6.4) id HAA25670; Fri, 28 Jan 1994 07:35:49 -0600 From: Pug Message-Id: <199401281335.HAA25670@ns1.arlut.utexas.edu> Subject: Re: Firewall router hardware for < $2k? To: bmanning@is.rice.edu (William Manning) Date: Fri, 28 Jan 1994 07:35:49 -0600 (CST) Cc: holbrook@cic.net, firewalls@GreatCircle.COM In-Reply-To: <9401280805.AA22311@is.rice.edu> from "William Manning" at Jan 28, 94 02:05:41 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 779 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > For the lowend, we like the cisco 2500 series. Comes in under the $2k limit > for us and does the job well. The problem with this is that the 2500 series doesn't come in an Ethernet-to-Ethernet configuration. (Atleast according to all of the documentation I've got my hands on.) We got a 3000 series Cisco just for this purpose. It's so far been able to keep up with all the traffic here although it's only been in place for a couple weeks under low to moderate load. Ciao, -- Richard Bainter Mundanely | System Analyst - OMG/CSD Pug Generally | Applied Research Labs - U.Texas pug@arlut.utexas.edu | pug@wixer.cactus.org Note: The views may not reflect my employers, or even my own for that matter. From Firewalls-Owner@GreatCircle.COM Fri Jan 28 14:22:55 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18736; Fri, 28 Jan 94 14:22:55 GMT Received: from tabasco.ansa.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18729; Fri, 28 Jan 94 06:22:43 PST Received: from outlaw.ansa.co.uk by tabasco.ansa.co.uk; Fri, 28 Jan 94 14:24:19 GMT Message-Id: <9401281424.tabasco.ansa.co.uk> Date: Fri, 28 Jan 1994 14:24:28 +0000 To: Paul Holbrook From: ajw@ansa.co.uk (Andrew Watson) X-Sender: ajw@outlaw Subject: Firewall router hardware for < $2k? Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Paul, You wrote: >What kind of hardware is out there that can do a reasonable job of >filtering IP traffic that costs less than $2000? (I'm not firm on that >number; if something is little more I'm interested.) Remember, we're >talking about ethernet-to-ethernet here. I believe that knocks out a few >of the low-end routers. What you need isn't so much a router as a filering bridge. Investigate the PD Karlbridge (aka kbridge) software. This is a filtering bridge that runs on a PC with two Ethernet cards. The software is free, and said to be good (although I don't use it myself). You can build the harware for it from a PC chassis with (probably) a 386SX motherboard and two decent Ethernet cards for less than $1000 (no monitor reqd). All this is from memory (this note comes to you from a Motel room in Salt Lake City!), but archie should be able to find "Karlbridge" or "kbridge" for you. If you have problems tracking it down, send me some mail and I'll send you the FAQ for the package when I get back into the office. Andrew From Firewalls-Owner@GreatCircle.COM Fri Jan 28 14:51:59 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18789; Fri, 28 Jan 94 14:51:59 GMT Received: from firewall.meaddata.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18782; Fri, 28 Jan 94 06:51:50 PST Received: from meaddata.com ([138.12.96.71]) by firewall.meaddata.com (4.1/SMI-4.1) id AA13173; Fri, 28 Jan 94 09:54:44 EST Received: from jungle.meaddata.com by meaddata.com (4.1/SMI-4.1) id AA01219; Fri, 28 Jan 94 09:54:30 EST Received: by jungle.meaddata.com (4.1/SMI-4.1) id AA07010; Fri, 28 Jan 94 09:54:28 EST From: sdw@meaddata.com (Stephen Williams) Message-Id: <9401281454.AA07010@jungle.meaddata.com> Subject: Re: Firewall router hardware for < $2k? To: brent@GreatCircle.COM (Brent Chapman) Date: Fri, 28 Jan 1994 09:54:27 -0500 (EST) Cc: holbrook@cic.net, firewalls@GreatCircle.COM In-Reply-To: <9401280234.AA15643@mycroft.GreatCircle.COM> from "Brent Chapman" at Jan 27, 94 06:34:49 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1792 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > Paul Holbrook writes: > > # What kind of hardware is out there that can do a reasonable job of > # filtering IP traffic that costs less than $2000? (I'm not firm on that > # number; if something is little more I'm interested.) Remember, we're > # talking about ethernet-to-ethernet here. I believe that knocks out a few > # of the low-end routers. > > When you say "ethernet-to-ethernet", do you mean it's got to have two > Ethernet interfaces, or do you mean that it's got to have Ethernet > performance levels? The first is true. ... > well within the capabilities of Ciscos with an old CSC/3 CPU card (and > that's what, 5-year-old technology?). I'd expect it to similarly be > within the capabilities of most current low-end IP routers. Your going to think I'm crazy probably, but I'm working (low priority) on adding firewall capabilities to Linux. A fast (enough) box with two ethernet cards, etc. would be <$1000. You've got source to the routing software (the whole OS in fact), ability to run proxy's (socks), etc. Of course BSDI is another option. box, MB (386 sx 40), 4MB, 170MB, 2 ether, io, mono mon, vga, key, floppy It could even handle slip/ppp for you. Someone had to suggest it sooner or later... > -Brent > -- > Brent Chapman Great Circle Associates > Brent@GreatCircle.COM 1057 West Dana Street > +1 415 962 0841 Mountain View, CA 94041 sdw -- Stephen D. Williams Local Internet Gateway Co.; SDW Systems 513 496-5223APager LIG dev./sales Internet: sdw@lig.net sdw@meaddata.com OO R&D Source Dist. By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430 Comm. Consulting ICBM: 39 34N 85 15W I love it when a plan comes together From Firewalls-Owner@GreatCircle.COM Fri Jan 28 15:21:12 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18931; Fri, 28 Jan 94 15:21:12 GMT Received: from ariel.ncsl.nist.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18924; Fri, 28 Jan 94 07:20:56 PST Received: from localhost (jwack@localhost) by ariel.ncsl.nist.gov (8.6.4/8.6.4) id KAA05811 for Firewalls@greatcircle.com; Fri, 28 Jan 1994 10:22:49 -0500 From: John Wack Message-Id: <199401281522.KAA05811@ariel.ncsl.nist.gov> Subject: Re: Firewall router hardware for < $2k? To: Firewalls@greatcircle.com Date: Fri, 28 Jan 94 10:22:49 EST In-Reply-To: ; from "Andrew Watson" at Jan 28, 94 2:24 pm X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We've been using CISCO IGS/L routers here and have had good performance. Last time around I thought these were selling for ~3K. This is not by any means an endorsement; I mention CISCO because that's all I'm familiar with. But, they do the job, are relatively cheap, and do all the packet filtering that the larger CISCOs do. The idea of doing the routing with PCs is attractive and something I'd like to explore here, but at the same time a cheap router such as the IGS/L, once configured, doesn't need much maintenance. This, of course, assumes that all you're interested in doing is packet filtering, period. Hope this helps, John Wack JWack@nist.gov ------------------------------------------------------------- All statements made are my own and do not reflect NIST policy ------------------------------------------------------------- From Firewalls-Owner@GreatCircle.COM Fri Jan 28 16:15:23 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19127; Fri, 28 Jan 94 16:15:23 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19120; Fri, 28 Jan 94 08:15:14 PST Message-Id: <9401281615.AA19120@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Fri Jan 28 11:12:09 EST 1994 To: ajw@ansa.co.uk (Andrew Watson) Cc: Paul Holbrook , firewalls@GreatCircle.COM Subject: Re: Firewall router hardware for < $2k? Date: Fri, 28 Jan 94 11:12:08 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk What you need isn't so much a router as a filering bridge. Investigate the PD Karlbridge (aka kbridge) software. This is a filtering bridge that runs on a PC with two Ethernet cards. The software is free, and said to be good (although I don't use it myself). You can build the harware for it from a PC chassis with (probably) a 386SX motherboard and two decent Ethernet cards for less than $1000 (no monitor reqd). Also check out the TAMU package. nisca.acs.ohio-state.edu:/pub/kbridge net.tamu.edu:/pub/security/TAMU All this is from memory (this note comes to you from a Motel room in Salt Lake City!), but archie should be able to find "Karlbridge" or "kbridge" for you. If you have problems tracking it down, send me some mail and I'll send you the FAQ for the package when I get back into the office. Gee -- such excuses! You could just run PPP and check archie... From Firewalls-Owner@GreatCircle.COM Fri Jan 28 16:27:05 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19196; Fri, 28 Jan 94 16:27:05 GMT Received: from volitans.MorningStar.Com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19189; Fri, 28 Jan 94 08:26:57 PST Received: from angel.MorningStar.Com by volitans.MorningStar.Com (5.65a/94011701) id AA28759; Fri, 28 Jan 94 11:28:53 -0500 From: Kate Murphy Received: by angel (5.65c/93060201) id AA02624; Fri, 28 Jan 1994 11:28:51 -0500 Date: Fri, 28 Jan 1994 11:28:51 -0500 Message-Id: <199401281628.AA02624@angel> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: Paul Holbrook Subject: Re: Firewall router hardware for < $2k? Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mr. Holbrook: Just a further note on low-end routers: Tom Easterday of CICNet, currently has one of the Morning Star Express routers for evaluation and testing purposes. Kate M. Murphy, Sales From Firewalls-Owner@GreatCircle.COM Fri Jan 28 08:38:55 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19176; Fri, 28 Jan 94 16:24:24 GMT Received: from volitans.MorningStar.Com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19169; Fri, 28 Jan 94 08:23:59 PST Received: from angel.MorningStar.Com by volitans.MorningStar.Com (5.65a/94011701) id AA28715; Fri, 28 Jan 94 11:25:47 -0500 From: Kate Murphy Received: by angel (5.65c/93060201) id AA02620; Fri, 28 Jan 1994 11:25:42 -0500 Date: Fri, 28 Jan 1994 11:25:42 -0500 Message-Id: <199401281625.AA02620@angel> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: Paul Holbrook Subject: Re: Firewall router hardware for < $2k? Cc: firewalls@greatcircle.com, kate@MorningStar.Com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mr. Holbrook: Received your message concerning low-end routers that support ethernet to ethernet connections, and filter IP traffic for less than $2K. The Morning Star Express Router 2e, has two 10 MBPS Ethernet/IEEE 802.3 AUI interfaces and one sync/aynch RS-232 DB-25 DTE interfaces. The following is pricing, payment, shipping and product specifications for your reference. I am enclosing a copy of MST Express at a Glance which provides the most recent specifications on the standards we support, features of the product, management and security issues etc.. Please note the paragraph at the end that points towards more information that you can FTP to your site. The list price of the router is $1,995.00 (US$). With the Frame Relay option, the list price is $2,245.00. (US$) We require that the product be paid prior to shipment. Payment can be made through Visa, MasterCard, wire transfer, or Purchase Order, net 30 days. After receipt of payment, product can be shipped within two to four weeks. (FOB MorningStar). Please do not hesitate to call if your require any additional information. We look forward to hearing from you soon. Kate Murphy, Sales Morning Star Express At A Glance (preliminary: November 1, 1993) Standards Support: - The Internet standard Frame Relay as defined in RFC 1294 - The Internet standard Point to Point Protocol (PPP) as defined in RFCs 1331, 1332, 1333, and 1334, with - Link-level error detection (16 or 32 bit FCS) - Asynchronous control character mapping - Packet size negotiation at connection time - Physical link loopback detection - IP address negotiation and assignment - PPP Addr/Ctl field and Protocol field compression - Link-level authentication by PAP or CHAP - Link status monitoring by LQM - The popular Serial Line Internet Protocol (SLIP), as described in RFC 1055 - automatically detects whether other end does TCP header compression (CSLIP) Optimal Performance: - `VJ' TCP packet header compression for SLIP and PPP as described in RFC 1144 - TCP `fast queue' for priority transmission of interactive packets - Asynchronous speeds to 115,200 baud - Synchronous speeds to T1 (1.544 Mb/sec) or CEPT (2.048 Mb/sec) Ease of Management: - SNMP MIB-II (RFCs 1442, 1445, 1448, 1450) - RIP (RFC 1058), RIP-2 (RFCs 1387, 1388), OSPF (RFC 1247) - Easy and extremely flexible configuration - Two RS-232 (sync or async), one V.35 (sync), and one AUI (Ethernet LAN) - Transparent on-demand dialup link establishment and idle line disconnection - Flexible `chat script' for dialup connection management - Operates as either the remote (calling) or hub (answering) site - Uses most asynchronous modems over dialup or dedicated lines - Configuration/negotiation problems reported in English, to console or syslog - Monitors PPP link status, reliability, and performance with LQM - Multiple line failover for redundancy and high availability - Thorough, readable documentation includes examples and troubleshooting tips - Flash memory for easy software upgrades, or can be downloaded by tftp Powerful Security Features: - Link-level peer authentication by PAP or CHAP - Packet filtering and logging by protocol, source, destination, source routing, etc. - Tunnels hidden via TCP over existing internet - Encrypts traffic between known-secure hosts or networks - Negotiates through security barriers like SecureID - Returns appropriate ICMP Destination Unreachable codes - Works with dialback modems Wide industry support: - Interoperates with network connectivity providers - PSInet - Merit - NEARnet - CSN - OARnet - Alternet - BARRNet - most EUnet members - CICnet - JvNCnet - MSEN - ANS - CERFnet - PREPnet - Sesquinet - NorthwestNet - AARNet - UKnet - PIPEX - Demon Internet Services - CyberNET - NETCOM - any other network that provides access via SLIP, PPP, or Frame Relay - Interoperates with other Frame Relay switches and routers - Cascade - cisco - Interoperates with other asynchronous and synchronous PPPs and SLIPs - Telebit NetBlazer - Livingston Portmaster IR-4 - 3Com NetBuilder - NAT LANB/820 - Proteon cnx500 - Cayman GatorBox - Brixton Systems BrxPPP - KA9Q - MERIT's MacPPP - ISC SLIP - Network Systems 6400 - Novell LAN WorkPlace - Novell MP Router - Datability terminal server - FTP Software PC/TCP - Intercon TCP/Connect II - Wellfleet - cisco AGS, CGS, IGS, 500-CS, STS-10 - BSDI PPP - HP PPL (SLIP) - Xylogics Annex-3 terminal server - Marble Associates Teleconnect - The popular free UNIX PPPs - Works with any asynchronous dial-up modem; pre-configured for - Most Telebit modems - Codex 3260 series - NEC N9631 - AT&T 2296 - UDS V.3224 and V.3229 - Forval SA9600, SA14400 - AT&T Datakit - Practical Peripherals 9600SA - Hayes V-series Ultra SmartModems - US Robotics V.32 and V.32bis - Digicom 9624E+ and V.32bis - Hayes ISDN System Adapter You can get all our marketing literature and the entire user guide from ftp.MorningStar.Com:pub/Express/MST-Express-User-Guide.ps.Z, or we'll be happy to send them to you via electronic mail or even on paper. Morning Star Technologies 1760 Zollinger Rd Columbus OH USA 43221-2856 +1 614 451 1883 (voice) +1 800 558 7827 (voice) +1 614 459 5054 (FAX) Marketing@Morningstar.Com (sales e-mail) Support@Morningstar.Com (technical e-mail) ftp.Morningstar.Com:pub/Express/* (anonymous FTP) http://WWW.Morningstar.Com/ (WWW) Acknowledgements This product includes software developed by the University of California, Berkeley and its contributors. From Firewalls-Owner@GreatCircle.COM Fri Jan 28 17:26:45 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19500; Fri, 28 Jan 94 17:26:45 GMT Received: from ncar.UCAR.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19493; Fri, 28 Jan 94 09:26:37 PST Received: from niwot.scd.ucar.EDU by ncar.ucar.EDU (8.6.4/ NCAR Central Post Office 03/11/93) id KAA15068; Fri, 28 Jan 1994 10:28:33 -0700 Message-Id: <199401281728.KAA24578@niwot.scd.ucar.EDU> Received: from localhost by niwot.scd.ucar.EDU (8.6.4/ NCAR Mail Server 04/10/90) id KAA24578; Fri, 28 Jan 1994 10:28:31 -0700 Subject: Re: Why, sure. Will UID=0 be OK ? To: firewalls@GreatCircle.COM Date: Fri, 28 Jan 94 10:28:31 MST From: era@ncar.ucar.edu (Ed Arnold) Reply-To: era@ncar.ucar.edu (Ed Arnold) X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Richard Huddleston wrote: > Here was an interesting request that found its way to my mailbox > at work today; has anyone else seen any of these? We got one of these a while back, at this site. Our answer was no. Interesting that Mr. R. Eric Felix has so much time on his hands, wonder why he can't find something useful to do? From Firewalls-Owner@GreatCircle.COM Fri Jan 28 19:57:48 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19858; Fri, 28 Jan 94 19:57:48 GMT Received: from ub4b.eunet.be (ub4b.buug.be) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19851; Fri, 28 Jan 94 11:57:28 PST Received: from sunbim.sunbim.be by ub4b.eunet.be (5.65c/ub4b_02) id AA21629; Fri, 28 Jan 1994 21:00:05 +0100 Received: from whitney.sunbim.be by sunbim.sunbim.be (4.1/SMI-4.1) id AA27061; Fri, 28 Jan 94 20:57:39 +0100 Received: by whitney.sunbim.be (5.0/SMI-SVR4) id AA18984; Fri, 28 Jan 1994 20:57:12 --100 Date: Fri, 28 Jan 1994 20:57:12 --100 From: db@whitney.sunbim.be (Danny Backx) Message-Id: <9401281957.AA18984@whitney.sunbim.be> To: firewalls@greatcircle.com Subject: Archie, WWW, Gopher proxies ? X-Sun-Charset: US-ASCII Content-Length: 374 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Can anybody point me to proxies (or anything) that would allow running things like Archie, Mosaic (WWW), Gopher, etc. through a firewall system ? Thanks, Danny -- Danny Backx System Engineer E-Mail: db@sunbim.be (or uunet!mcsun!ub4b!sunbim!db) Telephone: +32(2)759.59.25 Fax : +32(2)759.47.95 Postal Mail : Danny Backx BIM Kwikstraat 4 3078 Everberg Belgium From Firewalls-Owner@GreatCircle.COM Fri Jan 28 12:30:24 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19899; Fri, 28 Jan 94 20:01:08 GMT Received: from nic.cic.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19885; Fri, 28 Jan 94 12:00:48 PST Received: by nic.cic.net (4.1/2.25) id AA21335; Fri, 28 Jan 94 15:02:29 EST Date: Fri, 28 Jan 1994 15:02:28 -0500 (EST) From: Paul Holbrook Subject: Re: Firewall router hardware for < $2k? To: Kate Murphy Cc: firewalls@greatcircle.com In-Reply-To: <199401281628.AA02624@angel> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Yep, I've seen it; we just didn't realize it came in a two ether config. Thanks for the followup. -- Paul On Fri, 28 Jan 1994, Kate Murphy wrote: > Date: Fri, 28 Jan 1994 11:28:51 -0500 > From: Kate Murphy > To: Paul Holbrook > Cc: firewalls@greatcircle.com > Subject: Re: Firewall router hardware for < $2k? > > Mr. Holbrook: > > Just a further note on low-end routers: > > Tom Easterday of CICNet, currently has one of the Morning Star Express > routers for evaluation and testing purposes. > > Kate M. Murphy, Sales > > From Firewalls-Owner@GreatCircle.COM Sat Jan 29 14:18:44 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03163; Sat, 29 Jan 94 14:18:44 GMT Received: from tabasco.ansa.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03156; Sat, 29 Jan 94 06:18:30 PST Received: from outlaw.ansa.co.uk by tabasco.ansa.co.uk; Sat, 29 Jan 94 14:19:31 GMT Message-Id: <9401291419.tabasco.ansa.co.uk> Date: Sat, 29 Jan 1994 14:19:42 +0000 To: smb@research.att.com From: ajw@ansa.co.uk (Andrew Watson) X-Sender: ajw@outlaw Subject: Dial-up security (was Re: Firewall router hardware for < $2k?) Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 11:12 am 28/1/94 -0500, smb@research.att.com wrote: > All this is from memory (this note comes to you from a Motel > room in Salt Lake City!), but archie should be able to find > "Karlbridge" or "kbridge" for you. If you have problems > tracking it down, send me some mail and I'll send you the FAQ > for the package when I get back into the office. > >Gee -- such excuses! You could just run PPP and check archie... :-) Actually, the reason that I don't is sort-of relevant to firewalls, in that it concerns network security. I'd be interested in Firewallers' opinions of my set-up: There are about 40 users of the computer and network facilities at my site, including 10 permanently located off-site and a few more (my self included) who wish to have at least email access while travelling. The non-itinerant off-site users mostly have Macintoshes, and use MacTCP & MacPPP/MacSLIP to gain IP access via PSTN dial-up to our Netblazer router using V.32bis modems. We use the Netblazer's dial-back option to ensure that access comes only from known 'phone numbers; that, coupled with dial-up passwords secured against dictionary attack, gives me confidence that my internal network security can only be compromised via dial-up IP if the intruder physically breaks into one of the satellite locations and gains access to one of the dial-up Macs. This is an acceptable level of risk for us. The itinerant users present more of a problem. Dial-back is not a practical option; hotel switchboards get in the way, and dial-back accounts can only be set up during UK office hours, since that's when our sysadmin is at his desk. Portables holding authentication keys, passwords etc could easily be stolen, so I do not wish to allow unrestricted dial-up (as opposed to dial-back) IP access. My current solution is to allow dial-up access only to one Sun 3/60 on a separate ethernet to the rest of our machines. The Netblazer serves as a filering bridge between "internal" and "external" ethernets, providing the same level of packet filtering as I use to shield my internal machines against the Internet. The dial-in modem is also attached to the Netblazer; when a call comes through it is automatically telnetted through to this Sun. Users may either run a mail reader there or (as I do) use Eudora to batch dowload and upload mail via SMTP and POP running over the telnet link. The risk that a villain might dial up with a stolen or guessed password and steal or forge mail is deemed acceptable. OK, this was probably the longest-ever excuse for not doing an Archie search :-). However, I (and perhaps others?) would be interested to know how best to provide Internet services to roaming user with lap-tops without compromising the site's network security. Cheers, Andrew Andrew Watson ajw@ansa.co.uk APM Ltd +44 223 323010 (voice) Cambridge, UK +44 223 359779 (fax) From Firewalls-Owner@GreatCircle.COM Sat Jan 29 08:19:46 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03364; Sat, 29 Jan 94 15:50:05 GMT Received: from post.demon.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03355; Sat, 29 Jan 94 07:49:51 PST Received: from demon.demon.co.uk by post.demon.co.uk id ab29931; 29 Jan 94 15:48 GMT Received: from cellnet.uucp by demon.demon.co.uk id aa09292; 29 Jan 94 15:47 GMT From: Steve Kennedy Message-Id: <18587.9401291458@marvin.gbnet.org> Subject: Re: Firewall router hardware for < $2k? To: ansa.co.uk!ajw@gbnet.org Date: Sat, 29 Jan 94 14:58:36 GMT Cc: cic.net!holbrook@gbnet.org, greatcircle.com!firewalls@gbnet.org In-Reply-To: <9401281424.tabasco.ansa.co.uk>; from "Andrew Watson" at Jan 28, 94 2:24 pm X-Subliminal-Message: Send large quantities of used bills. X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Andrew, > What you need isn't so much a router as a filering bridge. Investigate the > PD Karlbridge (aka kbridge) software. This is a filtering bridge that runs > on a PC with two Ethernet cards. The software is free, and said to be good > (although I don't use it myself). You can build the harware for it from a > PC chassis with (probably) a 386SX motherboard and two decent Ethernet > cards for less than $1000 (no monitor reqd). The PD KarlBridge is available from nisca.asc.ohio-state.edu:/pub/kbridge ftp.demon.co.uk:/pub/ibmpc/kbridge +other archive sites also from my mail-server send mail to mail-server@gbnet.org any subject - in the body send /usr/ftp/pub/kbridge/kbdemo/kbridge.zip regards Steve -- ___ |_ ___ ___ Tel: +44 (0)71 483 1169 Voice (___ | (___) \ / (___) Data: 483 2454 WorldBlazer T3000 PEP+/v32bis... ___) | (___ \/ (___ Data: 483 2455 WorldBlazer T3000 V32bis/PEP+... ISDN: 722 7969/70 Email Snail Mail steve@gbnet.{org,com,net} [home] Steve Kennedy steve@marvin.demon.co.uk [DIS dialup internet] Flat 2, 43 Howitt Rd stevek@cellnet.co.uk [work] London, NW3 4LU From Firewalls-Owner@GreatCircle.COM Sat Jan 29 08:49:47 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03353; Sat, 29 Jan 94 15:49:36 GMT Received: from post.demon.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03346; Sat, 29 Jan 94 07:49:25 PST Received: from demon.demon.co.uk by post.demon.co.uk id ab29867; 29 Jan 94 15:48 GMT Received: from cellnet.uucp by demon.demon.co.uk id aa09282; 29 Jan 94 15:47 GMT From: Steve Kennedy Message-Id: <18455.9401291445@marvin.gbnet.org> Subject: Re: Firewall router hardware for < $2k? To: cic.net!holbrook@gbnet.org Date: Sat, 29 Jan 94 14:45:32 GMT Cc: greatcircle.com!firewalls@gbnet.org In-Reply-To: ; from "Paul Holbrook" at Jan 27, 94 4:27 pm X-Subliminal-Message: Send large quantities of used bills. X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > What kind of hardware is out there that can do a reasonable job of > filtering IP traffic that costs less than $2000? (I'm not firm on that > number; if something is little more I'm interested.) Remember, we're > talking about ethernet-to-ethernet here. I believe that knocks out a few > of the low-end routers. > I'd be interested in the basics: vendor name/model and approximate cost. > I'd also be interested in any comments (pro or con) about any of the > boxes. What do you recommend to people? Try the KarlBridge/KarlBRouter. The latest version (V2.x) will do tcp/ip, DECnet, AppleTalk (EtherTalk), and Novell protocol filtering. It can also do encryption, tunnelling of ANY Ethernet protocol within IP and may other firewall features. There is now wide area support (V35) and NCR WaveLAN support. For further info please contact sales@gbnet.com or sales@karlnet.com Regards Steve -- ___ |_ ___ ___ Tel: +44 (0)71 483 1169 Voice (___ | (___) \ / (___) Data: 483 2454 WorldBlazer T3000 PEP+/v32bis... ___) | (___ \/ (___ Data: 483 2455 WorldBlazer T3000 V32bis/PEP+... ISDN: 722 7969/70 Email Snail Mail steve@gbnet.{org,com,net} [home] Steve Kennedy steve@marvin.demon.co.uk [DIS dialup internet] Flat 2, 43 Howitt Rd stevek@cellnet.co.uk [work] London, NW3 4LU From Firewalls-Owner@GreatCircle.COM Sat Jan 29 19:26:33 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04132; Sat, 29 Jan 94 19:26:33 GMT Received: from uu6.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04125; Sat, 29 Jan 94 11:26:25 PST Received: by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA18574 for ; Sat, 29 Jan 94 14:13:19 -0500 Received: by crypto.com (5.67/3.2.012693-research); id AA04653 for GreatCircle.COM!Firewalls; Sat, 29 Jan 94 14:13:50 -0500 Message-Id: <9401291913.AA04653@crypto.com> To: Firewalls@greatcircle.com Subject: Re: Modem scanner Newsgroups: local.firewalls References: <1994Jan21.060142.23116@crypto.com> Date: Sat, 29 Jan 94 14:13:49 EST From: Matt Blaze Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In firewalls, Alastair Young (alastair@cadence.com) writes: >We were probed yesterday by someone looking for dialout modems. They tried >to telnet to all of our annex terminal servers (which are all handily >called (annexsomething) and gatorlink boxes. I wouldn't normally bother to >mention this other than the significant time period between each telnet >attempt, as if the hacker was going through a very long list, like maybe >everything with "annex" or "gator" in its name in the universe. The probes >came from sugar-bombs.gnu.ai.mit.edu 128.52.46.18. This is some kind of >public access system I think, and they are not interested in following this >up. On a related note, the latest (Winter '94) issue of "2600: The Hacker Quarterly" has 2.5 pages of Internet dialup numbers (most of which are at US Universities.) A few are noted as having "OUTDIAL" capabilities. From Firewalls-Owner@GreatCircle.COM Sun Jan 30 16:02:50 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07667; Sun, 30 Jan 94 16:02:50 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07660; Sun, 30 Jan 94 08:02:43 PST Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA13894; Sun, 30 Jan 94 08:03:52 PST Received: from UK.Sun.COM (sunuk) by snail.Sun.COM (4.1/SMI-4.1) id AA04314; Mon, 24 Jan 94 01:20:57 PST Received: from watchsun.UK.Sun.COM by UK.Sun.COM (4.1/SMI-4.1e-UK) id AA07134; Mon, 24 Jan 94 09:20:55 GMT Received: from zen.UK.Sun.COM by watchsun.UK.Sun.COM (4.1/SMI-5.0-sec(uk - sec)) id AA03089; Mon, 24 Jan 94 09:20:53 GMT Received: by zen.UK.Sun.COM (4.1/SMI-4.0) id AA15815; Mon, 24 Jan 94 09:20:46 GMT Date: Mon, 24 Jan 94 09:20:46 GMT From: Sean.Bennett@UK.Sun.COM (Sean Bennett - Sun UK - CS Hotline Engineer) Message-Id: <9401240920.AA15815@zen.UK.Sun.COM> To: jsz@ramon.bgu.ac.il, casper@fwi.uva.nl Subject: Re: Pings... Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Not quite - there is still that anoying xterm bug ;-) From Firewalls-Owner@GreatCircle.COM Sun Jan 30 16:40:14 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07740; Sun, 30 Jan 94 16:40:14 GMT Received: from dorsai.dorsai.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07733; Sun, 30 Jan 94 08:40:04 PST Received: by dorsai.dorsai.org (5.67b/29Dec93-Dorsai Embassy) id AA01839; Sun, 30 Jan 1994 11:41:48 -0500 Received: by squid.tram.com (5.59/27-Dec-93) id AA16243; Sun, 30 Jan 94 11:15:09 EST Date: Sun, 30 Jan 94 11:15:09 EST From: Jeffrey L Bromberger Message-Id: <9401301615.AA16243@squid.tram.com> In-Reply-To: Kate Murphy "Re: Firewall router hardware for < $2k?" (Jan 28, 22:54) Reply-To: X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: firewalls@greatcircle.com Subject: Re: Firewall router hardware for < $2k? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Jan 28, 22:54, Kate Murphy wrote: -> Tom Easterday of CICNet, currently has one of the Morning Star Express -> routers for evaluation and testing purposes. --- End of excerpt We're also using a MSE router for our firewall to the outside. While we have had a few problems with the Frame Relay software (related to New York Tel's service), it seems to be up now, and does a rather good job. The tech staff there know what's going on, and they return calls (!). I'm rather pleased with it. j -- Jeffrey L. Bromberger ------- System Manager ------- Tramway Unix Systems jeffrey@squid.tram.com Anywhere!{ccnysci,limbic,icus}!tram!jeffrey From Firewalls-Owner@GreatCircle.COM Mon Jan 31 04:05:57 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09559; Mon, 31 Jan 94 04:05:57 GMT Received: from post.demon.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09552; Sun, 30 Jan 94 20:05:46 PST Received: from esl-hub.demon.co.uk by post.demon.co.uk id aa00860; 31 Jan 94 4:01 GMT Path: esl-hub.demon.co.uk!dbuckley From: David Buckley Subject: Re: Firewalls Digest V3 #33 Reply-To: dbuckley@esl-hub.demon.co.uk References: <9401300900.AA06552@mycroft.GreatCircle.COM> To: Firewalls@greatcircle.com Message-Id: <759991706snx@esl-hub.demon.co.uk> X-Mailer: cppnews $Revision: 1.36 $ Date: Sun, 30 Jan 94 21:48:26 GMT Organization: Electric Solutions Ltd Lines: 32 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > From: ajw@ansa.co.uk (Andrew Watson) > Date: Sat, 29 Jan 1994 14:19:42 +0000 > Subject: Dial-up security (was Re: Firewall router hardware for < $2k?) > > [Stuff Deleted] > > The itinerant users present more of a problem. Dial-back is not a practical > option; hotel switchboards get in the way, and dial-back accounts can only > be set up during UK office hours, since that's when our sysadmin is at his > desk. Portables holding authentication keys, passwords etc could easily be > stolen, so I do not wish to allow unrestricted dial-up (as opposed to > dial-back) IP access. A good answer for this kind of problem is the magic box, the name of which escapes me, and the matching 'credit card' with LCD display that changes every minute or so. The box plugs in between your modem and presumably your NetBlazer. When the user dials in, (s)he gets a prompt, to which (s)he must reply the number displayed on the credit card. The box will grant access if the number is valid. Normally, the card is kept in a wallet, not with the portable, so if the portable gets 'lost', the 'new' user can't connect without the card as well... ----------------------------------------+------------------------------------ David Buckley of Electric Solutions Ltd | Email: dbuckley@cix.compulink.co.uk Services to the Computing,Electronics | dbuckley@esl-hub.demon.co.uk and Entertainment industries. | 2:254/90@fidonet ----------------------------------------------------------------------------- From Firewalls-Owner@GreatCircle.COM Mon Jan 31 17:46:32 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12524; Mon, 31 Jan 94 17:46:32 GMT Received: from chenas.inria.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12517; Mon, 31 Jan 94 09:46:09 PST Received: from edf.edf.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA26713; Mon, 31 Jan 1994 18:47:52 +0100 (MET) Received: from cli55ca.der.edf.fr by edf.edf.fr with SMTP id AA04053 (5.65c8/IDA-1.4.4 for ); Mon, 31 Jan 1994 18:48:17 GMT Received: by cli55ca.der.edf.fr (4.1/SMI-4.1) id AA15648; Mon, 31 Jan 94 18:48:19 +0100 Date: Mon, 31 Jan 94 18:48:19 +0100 From: Yves.Dherbecourt@der.edf.fr (Yves Dherbecourt) Message-Id: <9401311748.AA15648@cli55ca.der.edf.fr> To: Firewalls@greatcircle.com Subject: Secure Batch ftp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Securing Incoming ftp with a firewall + strong authentication (as SecurID) works fine as long as file transfer is done in "foreground", with a human user typing SecurID's response. But what if the file transfer is performed in "background", for example by cron every hour (night & day) ? One could think of a soft on the "client" side, simulating a SecurID card. Not really safe, nor adapted. The system is made to make sure the user is the one he claims. When there is no user, this system is nonsense. A system could be NOT to give access THROUGH the firewall, but to manage, ON the firewall, a spooling area, receiving the files. A special file, transferred after all the regular files, would mark the end of the transfer, and contain MACs of the regular files, (MACs made with a secet shared between the source and the dest parts). So the destination (inside) may authenticate that the source (outside) is the real originator. The dest part also knows that the transfer is not completed until the end mark is there, and verify the integrity of the files. Spooling area ? Anonymous ftp does provide one. Not confidential at all. But something as the sub-logins of anonymous ftp, just protected by a simple passwd, each sub-login giving access to an area accessible only from it (= protection 700). This may seem strange. I think that it makes sense, not for "very" confidential files, but that kind that you would'nt encrypt, but that you wouldn't leave in a public area too. Yes, you also need all a stuff to manage the spool, to notify source and destination, etc... and in a such a way that makes the system safe and reliable... I would greatly appreciate your opinion on the scheme described above ; or on any other that would be a better Secure Batch FTP system. And if something like this does already exist, please let me know. I already had a look at BFTP (that implements rfc1068) and batchftp, but they don't solve the firewall side of the problem. Moreover, I am not sure that BFTP's "intermediate "system controlling transfer between source and destination is the good approach in this case. Cheers #----------------------------------------------------------------------------# # Yves Dherbecourt | Tel : (1) 47 65 37 90 # # Electricite de France | Fax : (1) 47 65 35 23 # # DER / IMA / ICI / ASR | Tlx : 631576 # # 1, avenue du General de Gaulle | # # 92141 CLAMART Cedex | Email : Yves.Dherbecourt@der.edf.fr # # France | # #----------------------------------------------------------------------------# From Firewalls-Owner@GreatCircle.COM Mon Jan 31 10:49:51 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12779; Mon, 31 Jan 94 18:23:56 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA12768; Mon, 31 Jan 94 10:23:43 PST Received: by relay.tis.com; id AA01957; Mon, 31 Jan 94 13:25:54 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma001950; Mon Jan 31 13:25:08 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA04865; Mon, 31 Jan 94 13:24:29 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA11994; Mon, 31 Jan 94 13:24:28 EST Date: Mon, 31 Jan 94 13:24:28 EST From: mjr@tis.com Message-Id: <9401311824.AA11994@otter.tis.com> To: Firewalls@GreatCircle.COM, Yves.Dherbecourt@der.edf.fr Subject: Re: Secure Batch ftp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Securing Incoming ftp with a firewall + strong authentication (as SecurID) >works fine as long as file transfer is done in "foreground", with a human >user typing SecurID's response. >But what if the file transfer is performed in "background", for example >by cron every hour (night & day) ? The approach that seems most attractive is to have an FTP-like server (or maybe just a mail-responder) that checks for a digital signature on the message, and which then does the "right" thing if it's from a known user. For example, I might send a message that looks like: -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh HbGVud29vZA==,05 MIC-Info: RSA-MD5,RSA,VrjsX36CM6DtvZF8dIablHPga0Ax1ca9txZUYL0svxZ iJMFXq7TB8GpYmqozaQOTb8Bi8xITEoH9BSQxcEpAr+6dhD2jWicfnckFnRMKijA FWVY7dl66RAb6MLQwrV4T tar cf - /home/mjr/src/foo | compress | uuencode foo.tar.Z | mail mjr@tis.com -----END PRIVACY-ENHANCED MESSAGE----- Of course, the application that generates the signed message needs to have its key kept safely, somehow, since if someone can get the key, they can pretend to be the application. mjr. From Firewalls-Owner@GreatCircle.COM Mon Jan 31 19:03:19 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13035; Mon, 31 Jan 94 19:03:19 GMT Received: from clavin.uprc.com (uprc.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13028; Mon, 31 Jan 94 11:03:02 PST Received: from cygnus.uprc.com by clavin.uprc.com (4.1/3.2.012693-Union Pacific Resources Company); id AA09477 for firewalls@greatcircle.com; Mon, 31 Jan 94 13:03:25 CST Received: by cygnus.uprc.com (5.0/SMI-SVR4) id AA00473; Mon, 31 Jan 1994 13:02:42 +0600 Date: Mon, 31 Jan 1994 13:02:42 +0600 From: lacoursj@uprc.com (Jeffrey D. LaCoursiere) Message-Id: <9401311902.AA00473@cygnus.uprc.com> To: firewalls@greatcircle.com Subject: SecurID X-Sun-Charset: US-ASCII Content-Length: 287 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I am looking for vendor contacts to start gathering pricing/functionality of SecurID type systems. Am also interested in comments from anyone that has implemented such a system on their firewall. Thank in advance, Jeff LaCoursiere Network Admin UPRC Ft. Worth, TX lacoursj@uprc.com From Firewalls-Owner@GreatCircle.COM Mon Jan 31 11:49:52 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13137; Mon, 31 Jan 94 19:21:11 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13130; Mon, 31 Jan 94 11:21:03 PST Received: by relay.tis.com; id AA02738; Mon, 31 Jan 94 14:23:15 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma002731; Mon Jan 31 14:22:58 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA08595; Mon, 31 Jan 94 14:22:23 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA12428; Mon, 31 Jan 94 14:22:22 EST Date: Mon, 31 Jan 94 14:22:22 EST From: mjr@tis.com Message-Id: <9401311922.AA12428@otter.tis.com> To: firewalls@GreatCircle.COM, lacoursj@uprc.com Subject: Re: SecurID Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I am looking for vendor contacts to start gathering pricing/functionality >of SecurID type systems. Am also interested in comments from anyone that >has implemented such a system on their firewall. Here's a short list of some major players: --- Digital Pathways 201 Ravendale Drive Mountain View, CA 94043 Tel: (415) 964-0707 Fax: (415) 961-7487 Products: handheld authentication calculators (SNK004) serial line auth interruptors (guardian) --- Security Dynamics One Alewife Center Cambridge, MA 02140 Tel: (617) 547-7820 Fax: (617) 354-8836 Products: SecurID changing number authentication card ACE server software --- Racal Guardata 480 Spring park place Herndon, VA 22070 Tel: 1-800-521-6261 ext 217 Products: Watchword authentication calculator Encrypting modems Terminal servers --- Enigma Logic, Inc 2151 Salvio St, Ste. 301 Concord, CA 94520 Tel: (510)827-5707 Fax: (510)827-2593 Products: DES Silver card authentication calculator SafeWord Multisync card authentication calculator --- With respect to implementing such devices on one's firewall, the TIS toolkit supports Digital Pathways, SecurID and Enigma Logic (though I've only got a prerelease version of the Enigma Logic "glue" library) You can authenticate login, ftp, telnet, and rlogin using any combination of the above. For those who don't know, the toolkit is available for FTP from ftp.tis.com, pub/firewalls/toolkit We plan to release an upgrade version in a week or so. mjr. From Firewalls-Owner@GreatCircle.COM Mon Jan 31 12:49:52 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13460; Mon, 31 Jan 94 20:36:16 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13443; Mon, 31 Jan 94 12:36:00 PST Received: from elf.wang.com by tuna.wang.com with SMTP id AA06033 (5.67a/IDA-1.5 for ); Mon, 31 Jan 1994 15:37:54 -0500 Received: by elf.wang.com id AA16125 (5.67a/IDA-1.5); Mon, 31 Jan 1994 15:37:49 -0500 From: Tom Fitzgerald Message-Id: <199401312037.AA16125@elf.wang.com> Subject: Re: Archie, WWW, Gopher proxies ? To: db@whitney.sunbim.be (Danny Backx) Date: Mon, 31 Jan 94 15:37:48 EST Cc: firewalls@greatcircle.com In-Reply-To: <9401281957.AA18984@whitney.sunbim.be>; from "Danny Backx" at Jan 28, 94 8:57 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Can anybody point me to proxies (or anything) that would allow > running things like Archie, Mosaic (WWW), Gopher, etc. through > a firewall system ? udprelay will do proxying for archie (or any other UDP-based protocol). It can be found at ftp.wang.com:/pub/fitz/udprelay-0.2.tar.Z Socks will do mosaic and gopher. I don't have access info on this. -- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA From Firewalls-Owner@GreatCircle.COM Mon Jan 31 13:19:52 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13518; Mon, 31 Jan 94 20:37:53 GMT Received: from firewall.meaddata.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13501; Mon, 31 Jan 94 12:37:34 PST Received: from meaddata.com ([138.12.96.71]) by firewall.meaddata.com (4.1/SMI-4.1) id AA22732; Mon, 31 Jan 94 15:39:06 EST Received: from jungle.meaddata.com by meaddata.com (4.1/SMI-4.1) id AA03170; Mon, 31 Jan 94 15:39:09 EST Received: by jungle.meaddata.com (4.1/SMI-4.1) id AA14046; Mon, 31 Jan 94 15:39:05 EST From: sdw@meaddata.com (Stephen Williams) Message-Id: <9401312039.AA14046@jungle.meaddata.com> Subject: Re: Secure Batch ftp To: Yves.Dherbecourt@der.edf.fr (Yves Dherbecourt) Date: Mon, 31 Jan 1994 15:39:04 -0500 (EST) Cc: Firewalls@GreatCircle.COM In-Reply-To: <9401311748.AA15648@cli55ca.der.edf.fr> from "Yves Dherbecourt" at Jan 31, 94 06:48:19 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2832 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > Securing Incoming ftp with a firewall + strong authentication (as SecurID) > works fine as long as file transfer is done in "foreground", with a human > user typing SecurID's response. ... > A system could be NOT to give access THROUGH the firewall, but to manage, > ON the firewall, a spooling area, receiving the files. A special file, > transferred after all the regular files, would mark the end of the transfer, > and contain MACs of the regular files, (MACs made with a secet shared > between the source and the dest parts). So the destination (inside) may > authenticate that the source (outside) is the real originator. The dest > part also knows that the transfer is not completed until the end mark is > there, and verify the integrity of the files. > > Spooling area ? Anonymous ftp does provide one. Not confidential at all. > But something as the sub-logins of anonymous ftp, just protected by a > simple passwd, each sub-login giving access to an area accessible only > from it (= protection 700). This may seem strange. I think that it makes > sense, not for "very" confidential files, but that kind that you would'nt > encrypt, but that you wouldn't leave in a public area too. > > Yes, you also need all a stuff to manage the spool, to notify source and > destination, etc... and in a such a way that makes the system safe and > reliable... > > I would greatly appreciate your opinion on the scheme described above ; > or on any other that would be a better Secure Batch FTP system. > > And if something like this does already exist, please let me know. > I already had a look at BFTP (that implements rfc1068) and batchftp, > but they don't solve the firewall side of the problem. Moreover, I > am not sure that BFTP's "intermediate "system controlling > transfer between source and destination is the good approach in this > case. One way to use anon-ftp (or any user that is chrooted like anonymous/ftp) to provide a secure dropoff/pickup is to use blind directories: Don't allow read/execute permission on directories. Filenames can be made sufficiently long and random to prevent the possibility accidental discovery. I could put up files and be relatively certain that only the appropriate user received them. Of course, logging would verify this and the file could be encrypted. Similarly, a person dropping off a file could be required to name it in an agreed upon way. A write only file could be provided as a dropoff point. > Cheers > > Email : Yves.Dherbecourt@der.edf.fr # sdw -- Stephen D. Williams Local Internet Gateway Co.; SDW Systems 513 496-5223APager LIG dev./sales Internet: sdw@lig.net sdw@meaddata.com OO R&D Source Dist. By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430 Comm. Consulting ICBM: 39 34N 85 15W I love it when a plan comes together From Firewalls-Owner@GreatCircle.COM Mon Jan 31 23:12:31 1994 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14245; Mon, 31 Jan 94 23:12:31 GMT Received: from transfer.stratus.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14238; Mon, 31 Jan 94 15:12:23 PST Received: from localhost (jjm@localhost) by transfer.stratus.com (8.6.5/8.6.5) id SAA26349 for firewalls@GreatCircle.COM; Mon, 31 Jan 1994 18:14:23 -0500 From: Jim Murray Message-Id: <199401312314.SAA26349@transfer.stratus.com> Subject: Using established on router filters. To: firewalls@GreatCircle.COM Date: Mon, 31 Jan 1994 18:14:22 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 678 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I am using Cisco routers between my firewall net and the internal campus. Right now I have incomming tcp and upd >1023 blocked so only SOCKS or otherwise modified versions of telnet etc work. I am thinking of adding a rule permit tcp 0.0.0.0 255.255.255.255 mynet.mysubnet.0.0 0.0.255.255 established This will allow packets with RST or ACK set from ANY PORT to com in. The reason for doing this it ot allow unmodified telnet clients on various platforms to work. Does anyone see any security problems with this? Jim -- Jim Murray jjm@stratus.com Stratus Computer postmaster@stratus.com Marlboro MA root@stratus.com