From firewalls-owner Fri Dec 1 01:28:29 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id BAA18147 for firewalls-outgoing; Fri, 1 Dec 1995 01:06:23 -0800 (PST) Received: from wicked.neato.org (wicked.neato.org [198.70.96.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id BAA18142 for ; Fri, 1 Dec 1995 01:06:20 -0800 (PST) Received: (from george@localhost) by wicked.neato.org (8.7.2/8.6.12) id BAA17513; Fri, 1 Dec 1995 01:01:29 -0800 (PST) Date: Fri, 1 Dec 1995 01:01:29 -0800 (PST) Message-Id: <199512010901.BAA17513@wicked.neato.org> From: George Mullins To: "K Goertzel" cc: firewalls@greatcircle.com Subject: Re: A1 Systems? In-Reply-To: <9511301459.AA23737@hfsi> References: <9511301459.AA23737@hfsi> Sender: firewalls-owner@GreatCircle.COM Precedence: bulk K. Goertzel writes: > I just warn those on this group who hadn't already figured it out > for themselves that Mr. Ranum's extremely negative opinions vis the > NSA evaluation process are highly biassed and should in no way be > taken as fact, or even as representative of a rational opinion on > the subject. While TCSEC and ITSEC evaluations have their > problems, Mr. Ranum, an ex-TIS employee who clearly feels he was > somehow "burned" by the TCSEC evaluation process at "high > assurance" levels, clearly has an axe to grind that prevents him > from providing anything like a helpful, well-reasoned opinion of > these matters. And of course you, who is trying to sell TCSEC and ITSEC systems and who's business life is based on these "secure" systems is totally unbiased in this. At least Marcus doesn't have such an obvious profit motive as you do in your postings to the list. > As for his opinions on MULTICS, I happen to know many dozens of > former Multicians, all of whom would loudly disagree with his "one > man's opinion". But who are all probably in a different field now. All of the Multicians I know are. > I do not wish to start a flame war with Mr. Ranum, but I have been > following his opinions on high-assurance evaluations for several > months now, and have yet to find anything like a calm, > well-reasoned opinion in any of his diatribes on the subject. And of course we should all listen to your marketing hype and take it as fact? She who lives in glass houses shouldn't throw stones. -george From firewalls-owner Fri Dec 1 01:54:11 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id BAA18857 for firewalls-outgoing; Fri, 1 Dec 1995 01:17:44 -0800 (PST) Received: from northshore.ecosoft.com (northshore.ecosoft.com [192.233.85.129]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id BAA18852 for ; Fri, 1 Dec 1995 01:17:40 -0800 (PST) Received: from [198.115.179.219] (slip-3-5.shore.net) by northshore.ecosoft.com with SMTP id AA13814 (5.67a/IDA-1.5 for ); Fri, 1 Dec 1995 04:17:49 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Dec 1995 05:24:45 -0500 To: lear@yeager.corp.sgi.com (Eliot Lear) From: vin@shore.net (Vin McLellan) Subject: Re: SDI's Time-Synched SecurIDs (3 of 3) Cc: Firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >Just one question about SDI. > >Do you know what the algorithm is? How does it compare to DES? > Nope, I don't know the algorithm. And, frankly, I would not be able to evaluate the security or integrity of a one-way function, or any other cryptographic construct;-) The ACE/SecurID algorithm is SDI proprietary. The only meaningful comparison I can make between such a keyed hash and a secret key algorithm like DES is on the key length, which (I presume) says something about the relative strength of the two algorithms in the face of a brute force attack. DES uses a 56 bit key. The ACE/SecurID uses a 64-bit key, I think. (I recall an SDI document which said it was longer than DES.) Any serious cryptographic evaluation or comparison would deal with a variety of other attack and cryptoanalytic modes, including algebraic, statistical, and structural, among others, in addition to the brute force comparison. SDI clients and serious potential clients -- or their agents, if they need an outside evaluation -- can review both the code and the algorithm under an NDA. Many have. SDI could, and probably would, also make available some of the test reports they regularly commission from notable independent cryptographers -- which, at the least, gives the people evalulating it tomorrow the benefit of some of the work done by others yesterday. _Vin Vin McLellan +The Privacy Guild+ 53 Nichols St., Chelsea, Ma., USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*> From firewalls-owner Fri Dec 1 02:24:12 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id BAA19518 for firewalls-outgoing; Fri, 1 Dec 1995 01:58:33 -0800 (PST) Received: from venere.inet.it (venere.inet.it [194.20.8.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id BAA19503 for ; Fri, 1 Dec 1995 01:58:20 -0800 (PST) Received: from argo.omnitel.it (argo.omnitel.it [194.20.66.105]) by venere.inet.it (8.6.10/8.6.10) with ESMTP id JAA56082 for ; Fri, 1 Dec 1995 09:59:04 GMT Received: (from apakter@localhost) by joanne.omnitel.it (8.6.12/8.6.12) id KAA25657 for firewalls@GreatCircle.COM; Fri, 1 Dec 1995 10:59:02 +0100 From: Alex Pakter Message-Id: <199512010959.KAA25657@joanne.omnitel.it> Subject: By request: buffer attack explanation To: firewalls@GreatCircle.COM Date: Fri, 1 Dec 1995 10:59:02 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hi All- Several people have written to me, asking for information on the buffer overflow-type attack. Attached below are two of the most interesting responses that I got. I wrote: > QUESTION: How does it work? OK, you feed the server too much input, it > overwrites the (supposedly stack-allocated) buffer, and writes what you want > onto the programs's stack. And then? How to you get from there to a > break-in? And others told me: ----------------------response No. 1--------------------------- From: Dermot Tynan (dtynan@ilo.dec.com) Digital Equipment International BV, Galway, Ireland I know of at least two methods for subverting a system using buffer overruns. Take the following (static) declarations... char buffer[512]; char prog[64]; The program initializes prog[] to contain the name of some process it wants to fire off, such as /sbin/sendmail. It then uses a gets() call to fill buffer[] with data that I provide. There are no controls on how much data gets() will accept. The 513th byte will be deposited into prog[0]. If I send a very long string, with some data at the front, nulls up to 512, and then "/bin/sh\0" as the next 8 bytes, I've subverted the program. My "mail message" is then directed to /bin/sh instead of sendmail. The second example is more difficult and requires a CPU architecture which *isn't* split I&D. Essentially I hand-code a little program which opens a file, and spits some data into it. Perhaps I have a small program to read from a socket, put the data into another executable, and then run it. I assemble this program to run in the stack area of the buffer (presuming of course that "buffer[]" in this case is an automatic variable), and rewrite the return address on the stack. The average stack (not all, mind you) works downward. If we look at high memory, where the stack is before the call, the return program counter is pushed (down), the frame pointer is usually pushed, and any register variables which need to be saved. Then, the size of the auto variables is subtracted from the stack pointer. Thus, if we had a little 16-bit box, with a stack pointer of 0xf000, we'd have a stack frame as follows; 0xf000: 0xeffe: 0xeffc: 0xeffa: . . . 0xedfa: I've given a simple response for the gets() call, followed by a few nulls, and perhaps at 0xee00 I have my mini bootstrap program. I blow away the register variables and the frame pointer, and replace the return address with 0xee00. The routine returns, not to the original caller but to my mini-stack-routine. There are other methods, but you get the general idea. - Der ----------------------response No. 2 --------------------------- From: David Vincenzetti Computer Emergency Response Team ITaly (CERT-IT) e-mail: cert-it@dsi.unimi.it URL: http://security.dsi.unimi.it/cert-it.html In <199509270932.KAA01892@meteo.cling.gu.se> you write: > Hey folks, I need to know about this 'stack overwriting thing' > thet is so lively discussed. As I understand it (and correct me > if I'm wrong), the point is to pass in data to a non-bound > checking routine (like syslog), and make it so constructed > that it 'rewrites' some parameters on the stack. > Subsequent routines will then pop these phoney params and > off we go... > Am I right? Can anybody provide me with more detailed info > and perhaps some harmless example (please please please!!!) Well, since this seems like a question that lots of people ask, I'll give a high level description of how this works; there are several people working on exploits for explicit programs that can be examined. For those that are about to flame me for answering this on bugtraq, I'm hoping this will reduce the number of other folks asking basically this question. For a simple example, consider a C routine like: full_of_holes(int x) { char buf[2]; gets(buf); return atoi(buf) + x; } When full_of_holes is called, the value for x is pushed on the stack and a subroutine call is made, which pushes a return address, etc. on the stack. Then a two byte area is allocated, and the address of it is pushed on the stack, and we call fgets. The stack now looks like this (assuming the stack pointer was at location 1000 when we called full_of_holes ffff1000: 5 value of x ffff1004: 00001234 return address for caller of full_of_holes ffff1008: ffff1010 other function call stuff ffff100C: 0 buf[0], buf[1] two bytes of pad ffff1010: 100C address of buf[0] ffff1014 00004567 return address for caller of gets ffff1018: ffff1010 other function call stuff ffff101C: 1 first local variable for gets. .... Now lets say for the sake of argument that gets is about to read a line with more than two characters on it. In particular lets assume it some magic bytes such that when we have read it into buf, the stack now looks like: ffff1000: 5 value of x ffff1004: 00001234 return address for caller of full_of_holes ffff1008: ffff1010 other function call stuff ffff100C: deadbeef buf[0], buf[1] two bytes of pad ffff1010: deadbeef address of buf[0] ffff1014 ffff1018 return address for caller of gets ffff1018: xxxxxxxx other function call stuff ffff101C: xxxxxxxx first local variable for gets. .... where the data read by gets was the "deadbeefdeadbeefffff1010xxxxxxxxxxxxxxxx.. ." (in hex), and xxxxxx.... is some happy executable code on this hardware. we now go to return from gets, which grabs address ffff1018 off the stack, and shoves it in the program counter. You then proceed to execute the code xxxxx.... Marc ------------------------end of response No. 2-------------------------- Alex | Alex Pakter - UNIX systems analyst ---- | Omnitel Pronto Italia - Milano, Italy | Internet Mail: Alex.Pakter@omnitel.it | WWW Home Page: http://idiom.com/~alex (in progress) From firewalls-owner Fri Dec 1 02:54:12 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA20416 for firewalls-outgoing; Fri, 1 Dec 1995 02:28:43 -0800 (PST) Received: from crc.u-strasbg.fr (crc.u-strasbg.fr [130.79.200.20]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id CAA20406 for ; Fri, 1 Dec 1995 02:28:34 -0800 (PST) Received: (from balzinge@localhost) by crc.u-strasbg.fr (8.6.11/8.6.9) id LAA08265 for firewalls@GreatCircle.COM; Fri, 1 Dec 1995 11:24:12 +0100 Date: Fri, 1 Dec 1995 11:24:12 +0100 From: Laurent Balzinger - Centre Reseau Communication - Universite Louis Pasteur Message-Id: <199512011024.LAA08265@crc.u-strasbg.fr> To: firewalls@GreatCircle.COM Subject: TIS & Linux 1.3 X-Sun-Charset: US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hi FWG, I'm new to network security. Please consider me like an eternel beginner. First I'd like to congratulate people on this list for its quality and sometimes 'Humour and flames policy' that precisely make this list (Padgett & co') OK. More seriously I'd like to know if someone has already implement TIS in Linus box. If so, where can I find a FTP site. On the other hand , considering that Internal FW represent an increasing need in corporate networks, is there a relatively simple way to treat Appletalk and IPX as well as IP in an APPLICATION level ( I have in mind the adaptation of TIS for other protocols and services). Maybe the product exist, maybe I'm in wrong way , maybe it's simply not possible (technicaly) on the same station (i.e. TIS ->IP/Appletalk/IPX). Thanks for any advice or experience. From firewalls-owner Fri Dec 1 03:24:12 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id DAA21422 for firewalls-outgoing; Fri, 1 Dec 1995 03:07:55 -0800 (PST) Received: from ns.dknet.dk (ns.dknet.dk [193.88.44.42]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id DAA21417 for ; Fri, 1 Dec 1995 03:07:44 -0800 (PST) Received: from ecad (uucp@localhost) by ns.dknet.dk (8.6.12/8.6.12) with UUCP id MAA27625 for firewalls@GreatCircle.COM; Fri, 1 Dec 1995 12:08:29 +0100 Received: from soeren by ghdsign.dk (5.x/SMI-SVR4) id AA16011; Fri, 1 Dec 1995 11:51:31 +0100 Received: (from pm@localhost) by soeren (8.6.9/8.6.9) id LAA29818; Fri, 1 Dec 1995 11:52:19 +0100 Date: Fri, 1 Dec 1995 11:52:19 +0100 From: Peter Maersk-Moller Message-Id: <199512011052.LAA29818@soeren> Subject: port number to process id To: firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hi Firewall list ! Is there a standard way/script/tool (must cover most un*ces) to find the relation between IP port number in use and id of the process using the port ? Thanks in advance. Peter Maersk-Moller --- Technical Manager E-mail maersk@ghdsign.dk Peter Maersk-Moller GSM +45 40164125 ------- GHDsign Phone +45 44441482 Bakkesvinget 12 Fax +45 44490044 DK-2880 Bagsvaerd BBS +45 44440940 DENMARK \|||/ (. .) -----------------------------ooO-(_)-Ooo--------------------------------- __ _ / / (_)__ __ ____ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a /____/_/_//_/\___/ /_/\_\ G N U g e n e r a t i o n . . . ------------------------------------------------------------------------- || || ooO Ooo From firewalls-owner Fri Dec 1 03:54:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id DAA21934 for firewalls-outgoing; Fri, 1 Dec 1995 03:32:14 -0800 (PST) Received: from zeus.ci.ua.pt (zeus.ci.ua.pt [193.136.80.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id DAA21927 for ; Fri, 1 Dec 1995 03:32:05 -0800 (PST) Received: by zeus.ci.ua.pt (1.37.109.16/16.2) id AA148660927; Fri, 1 Dec 1995 12:28:47 GMT From: Fernando Cozinheiro Message-Id: <199512011228.AA148660927@zeus.ci.ua.pt> Subject: Re: FREE Proxy Server? To: Ming-Ching.Tiew@Malaysia.Sun.COM (Ming Ching Tiew) Date: Fri, 1 Dec 1995 12:28:47 +0000 (PWT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9512010308.AA03799@sparrow.Malaysia.Sun.COM> from "Ming Ching Tiew" at Dec 1, 95 11:08:30 am Organization: Universidade de Aveiro, Portugal X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > > > Anybody has an answer to this ? > > ----- Begin Included Message ----- > > Subject: FREE Proxy Server? > > Dear Consultants, > > Do U know of any FREE-ly available http proxy server, providing a similar function to > Netscape Proxy Server? > > Regards, > > > -Raymond Chan > [rchan@abs.com.my] > > > ----- End Included Message ----- > There are several public domain proxy servers. I know the following: CERN HTTPD http://www.w3.org/hypertext/WWW/Daemon/ Harvest Cache and HTTPD Accelerator http://harvest.cs.colorado.edu/harvest/ Lagoon http://www.win.tue.nl/lagoon/ But you can see the Yahoo section about caching: http://www.yahoo.com/Computers_and_Internet/ Internet/World_Wide_Web/Caching/ Does anyone know any others? -- Fernando Cozinheiro http://sweet.ua.pt/~cooker/ System & Network Administrator Email: cooker@ci.ua.pt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Universidade de Aveiro Phone: Centro de Informatica UA: +351 34 370200/Ext.2254 3810 Aveiro CIUA: +351 34 370345 Portugal Telefax: +351 34 370214 From firewalls-owner Fri Dec 1 05:24:12 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA24815 for firewalls-outgoing; Fri, 1 Dec 1995 05:00:11 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id EAA24767 for ; Fri, 1 Dec 1995 04:59:58 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id IAA19126 for ; Fri, 1 Dec 1995 08:00:22 -0500 Date: Fri, 1 Dec 1995 08:00:22 -0500 Message-Id: <199512011300.IAA19126@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@greatcircle.com From: Anton J Aylward Subject: RE: chroot() and all that.... Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Before I get drowned in mail about firewalls as embedded systems vs machines running proxies..... Just because you CAN do a thing doesn't mean that you SHOULD do it. Remember too, that there are many situations out there in the market place, and no one solution will fit them all. Before you flame^H^H^H^H^H drown Marcus, Padgett, Myself or anyone else in mail, ask yourself "What situation could exist in which this is not only an applicable solution, but the RIGHT one". Untill you have more than one member of that solution set, hold your fire. Thanks. /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Fri Dec 1 05:59:43 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA24836 for firewalls-outgoing; Fri, 1 Dec 1995 05:00:50 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id FAA24831 for ; Fri, 1 Dec 1995 05:00:43 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id IAA19149 for ; Fri, 1 Dec 1995 08:01:06 -0500 Date: Fri, 1 Dec 1995 08:01:06 -0500 Message-Id: <199512011301.IAA19149@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@greatcircle.com From: Anton J Aylward Subject: Re: chroot/setuid vs type enforcement Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 10:58 28/11/95 CST, jeromie@garrison.com wrote: > ... I myself feel the KISS approach is always best, and type >enforcement seems to break this rule. Having spent a chunk of my professional life building systems on which thousands of people's lives depend, I whole heartedly agree with with the KISS approach. However, I've seen what _should_ be simple systems which have been coded in ways which are overly esoteric. And bloated way beyond what is necessary to do the job. Some of the stuff with the GNU label illustrates this. Thanks for binging this up. /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Fri Dec 1 06:24:12 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA24847 for firewalls-outgoing; Fri, 1 Dec 1995 05:01:19 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id FAA24839 for ; Fri, 1 Dec 1995 05:01:10 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id IAA19160 for ; Fri, 1 Dec 1995 08:01:31 -0500 Date: Fri, 1 Dec 1995 08:01:31 -0500 Message-Id: <199512011301.IAA19160@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@greatcircle.com From: Anton J Aylward Subject: Re: chroot/setuid vs type enforcement Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 21:55 28/11/95 CST, jeromie@garrison.com wrote: >> >1) >> >type enforcement provides multiple domains that allow for seperation of duty. >> >> Kinda like you can do with setuid, chroot, or VMS ACLs >> if you know what you're doing. >> > I have received some interesting mail in reguards to my above mentioned commment. Something the scts folk have been telling me is that one major >advantage to type enforcement is that it is not vulnerable to buffer overflow >errors, and that chroot() is vulnerable. IE: If you can get a program to execute code, you could have it exec network calls, create a new device, and gain >access to the entire filesystem. I am not THAT much of a coder to be able to >prove anything either way... Any assistance anyone?!?!? I havn't seen EVERY version of UNIX out there, but none of the kernels I HAVE seen would allow what you describe in the way you describe it. The only "buffer" involved in the chroot() call is in user space, is already filled in with thename of the new root. The kernel doesn't need to have a buffer. It just maps space, tries to access this file. If that access fails the chroot() fails. If it suceeds, that directory becomes thenew root for the process and its children. The chroot() call has to be in the code, it doesn;t deal with anything which may have been communicated from some (possibly network) input stream. Now if the situation was to read the directory to chroot to from a network connection, maybe that buffer could be trashed, but that logic applies to input, even when you tell FTP what file to download. Hmmmmm! >> >2) >> >type enforcement allows for the removal of system calls from any given >> > domain. Sounds like permission vectors to me, and all the problems which go along their implementation. A firewall OUGHT to be an embedded system, not a general purpose computing platform, although I know there are many systems - such as the Harris NightHawk - which advocate running services on the firewall machine. I don't subscribe to this approach. A firewall as an embedded system means that a great deal of the kernel can be removed. For example, there is no need to create directories, so there is no need for the "mkdir" system call. Ditto the "mknod" call. (I leave it as an excercise for the proverbial reader why this is the case in embedded systems). >In summary, the strongest feature touted by sctc is that chroot() is vulerable >to buffer overflows. If that is so, then the whole argument collapses. >Jeromie Jackson >Garrison Associates >jeromie@garrison.com /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Fri Dec 1 06:45:41 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id EAA24768 for firewalls-outgoing; Fri, 1 Dec 1995 04:59:59 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id EAA24750 for ; Fri, 1 Dec 1995 04:59:50 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id IAA19122; Fri, 1 Dec 1995 08:00:06 -0500 Date: Fri, 1 Dec 1995 08:00:06 -0500 Message-Id: <199512011300.IAA19122@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mjr@iwi.com From: Anton J Aylward Subject: Re: chroot/setuid vs type enforcement Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Sigh. Sounds like a religious war to me. I used to be a UNIX kernal hacker. I gave it up when I saw the quality of the other programs and programmers I had to deal with. But then, having started life in military avionics, I'm a bit of a bigot about "Quality". So what does this have to do with chroot() vs. other things? Yes, a UNIX guru, or even a second level wizzard, can do all manner of protection most sysadmins wouldn't believe WITHOUT KERNEL HACKS. Many can be done without writing a line of code. But that isn't the point. IMHO there are two points: a) the market is demanding that the sysadmin is also the security admin, and that (s)he is a low cost item, probably someone with less than 5 years experience. Therefore, all "us" "experts" have to embed experience and knowledge in chunks of software. Hence any fool can use it - and probably a lot of fools will. (This used to be called expert systems, a term which is pure bunkum; a compiler is an expert system in code generation by much the same principle.) Different experts have different opinions. Fine. The marketplace is broad enough to accept different techniques. What worries me is the quality of the implementation. b) Maybe, just maybe, the two techniques under debate are ismorphisms - equivilent but different. However, I remember the UNIX V6 kernal and its application code package. I could pretty near memorise the kernel. My point here is that every metric about software quality has as its first parameter the VOLUME of code Adding all these other access control structures may give more power and granularity, but they take more code to implement. More NEW code. Then I remember VMS, the operating system which could be configured to be all things to all men. I also recall the volume of code that was required. Some of the things I hear about TYPE ENFORCEMENT which remind me of the VMS permission vectors. And I think of moving the attack base from buffer over-run to subverting these vectors. I'm sure VMS hackers will be able to bring expereince to bear. But what I'm really bothered about is the sheer VOLUME of code. Twenty years on, I see most programmers, be it with 3 years experience of 10 years, were never taught some of the old principles of Structured Programming. The ones to do with modules interacting. Things about coherency, about shared global variables. Its as if most were self-taught andrepeat the problems of one, two, thre generations ago. I dispair at what I see in some major (e.g financial) institutions. So anything which adds more *new* code bothers me. MJR's two-line change is the kind of thing that appeals to me. Despite the shortcomings of the UNIX kernel, the change is minimal, and its effects are well bound. Given that the root vnode is global, which is the real design flaw, it does the least damage. Dennis Ritchie, I think it was, once wrote an excellent paper which described the UNIX kernel as a process scheduler and I/O manager. We now take that for granted, the monoliths which had everything as part of the operating system have passed on. However, I see "engineers" (in general and "programmers" in particular) justifying their existence by re-engineering that which is already working fine. We used to say "If it ain't broke don't fix it" and decry creeping featurism. Now, managers seem to by on the basis of the length of the bullet-list (or feature list) and engineering is driven and directed by the sales department. I wonder what the president of Honda has to say about this now? All this bothers me, mostly becuase I see so many corporations short changing their security needs. Its like arguing about the choice of Nero's selections while Rome burns. /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Fri Dec 1 06:54:12 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA27486 for firewalls-outgoing; Fri, 1 Dec 1995 06:45:39 -0800 (PST) Received: from gki.com (voodoo.Cryptek.Gki.COM [198.6.120.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA27481 for ; Fri, 1 Dec 1995 06:45:34 -0800 (PST) Received: from vampire.cryptek.gki.com by gki.com (4.1/SMI-4.1/ccg.7.2.91) id AA08988; Fri, 1 Dec 95 09:46:25 EST Received: by vampire.cryptek.gki.com (4.1/SMI-4.1) id AA00791; Fri, 1 Dec 95 09:46:27 EST Date: Fri, 1 Dec 95 09:46:27 EST From: williams@gki.com (Tim Williams) Message-Id: <9512011446.AA00791@vampire.cryptek.gki.com> To: firewalls@greatcircle.com Subject: Re: A1 Systems? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Mr Ranum writes: > It's not about features, it's about assurance. > Commercial computing is about features (represented as functionality) > Therefore orange book is irrelevant to commercial computing. Yes in the trully commercial environment it is always about functionallity until something really goes south (your hard disk gets wiped or someone's little program sends the boss's little black book to his wife via email). Then that site looks to see why this happended. Usually its a commercial program (or OS) that has given someone access to something he should not have. Now depending one how much the wife got in the settlement case it might have been cheaper to place a high assurance system guarding such important information. Tim Williams williams@gki.com From firewalls-owner Fri Dec 1 07:24:12 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA27881 for firewalls-outgoing; Fri, 1 Dec 1995 07:00:05 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA27848 for ; Fri, 1 Dec 1995 06:59:58 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id JAA12874; Fri, 1 Dec 1995 09:02:01 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id JAA12867; Fri, 1 Dec 1995 09:02:00 -0600 Received: from mario.sctc.com (mario.sctc.com [172.17.192.177]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id JAA00769; Fri, 1 Dec 1995 09:01:21 -0600 (CST) Received: (from dowd@localhost) by mario.sctc.com (8.6.12/8.6.9) id JAA05656; Fri, 1 Dec 1995 09:01:19 -0600 Date: Fri, 1 Dec 1995 09:01:18 -0600 (CST) From: Alan Dowd To: Anton J Aylward cc: firewalls@GreatCircle.COM Subject: RE: chroot() and all that.... In-Reply-To: <199512011300.IAA19126@psyche.the-wire.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Fri, 1 Dec 1995, Anton J Aylward wrote: > Before I get drowned in mail about firewalls as embedded > systems vs machines running proxies..... > > Just because you CAN do a thing doesn't mean that you SHOULD > do it. One of my favorite lines from _Jurrasic Park_ - I use it often. > Remember too, that there are many situations out there in the > market place, and no one solution will fit them all. Before you > flame^H^H^H^H^H drown Marcus, Padgett, Myself or anyone else > in mail, ask yourself "What situation could exist in which this is > not only an applicable solution, but the RIGHT one". Untill > you have more than one member of that solution set, hold > your fire. But interesting and fruitful discussions can come from debating whether even a single-member solution set meets the criteria of both applicability and correctness. Regards, Al Dowd Secure Computing Corporation From firewalls-owner Fri Dec 1 07:54:12 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA26671 for firewalls-outgoing; Fri, 1 Dec 1995 06:13:45 -0800 (PST) Received: from galil.austnsc.tandem.com (stocking.mpd.tandem.com [131.124.250.12]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id GAA26666 for ; Fri, 1 Dec 1995 06:13:41 -0800 (PST) Received: (from dreschs@localhost) by galil.austnsc.tandem.com (8.7.1/8.7.1) id IAA26863; Fri, 1 Dec 1995 08:16:39 -0600 (CST) Date: Fri, 1 Dec 1995 08:16:39 -0600 (CST) From: Sten Drescher Message-Id: <199512011416.IAA26863@galil.austnsc.tandem.com> To: CC: sgcccdc@citec.qld.gov.au, vanuskae@halsp.hitachi.com In-reply-to: Eric Vanuska's message of Thu, 30 Nov 1995 14:30:19 -0800 Subject: Re: is a second filter router worthwhile? References: <9511300754.AA18106@citecub.citec.qld.gov.au> <30BE307B.45EC@halsp.hitachi.com> Cc: Eric Vanuska Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Eric Vanuska said: EV> Colin, Thanks for your reply. Your comment below is at the heart of EV> what I'm asking. >> Deleted cogent remarks about the importance of the last line of >> defense and having your filters closest to where they are needed. >> You allow TCP only to ports > 1023 to everyone. Unfortunately this is >> the biggest security hole. It is needed for FTP to work. It also >> means you have to be very careful about what servers are running on >> port > 1023 on the inside, or close your eyes and hope noone gets >> that close. >> EV> Agreed, with vanilla TCP the ftp server creates a new TCP connection EV> back to the client on destination port > 1023 and return port EV> 21. With TIS the initial TCP destination port is bumped up to some EV> higher number (> 30,000). Well, the SOCKS ftp client uses (I think) the PASV command to tell the ftp server to use passive TCP ports for transfers. That is, rather than the ftp server creating the connection to the client, it opens a port, tells the client what port to connect to, and waits for the client to create the connection. This way, the connection is originating inside the SOCKS firewall, instead of outside it. -- #include /* Sten Drescher */ To get my PGP public key, send me email with your public key and Subject: PGP key exchange Key fingerprint = 90 5F 1D FD A6 7C 84 5E A9 D3 90 16 B2 44 C4 F3 From firewalls-owner Fri Dec 1 08:04:46 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA27153 for firewalls-outgoing; Fri, 1 Dec 1995 06:34:33 -0800 (PST) Received: from gki.com (voodoo.Cryptek.Gki.COM [198.6.120.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA27148 for ; Fri, 1 Dec 1995 06:34:26 -0800 (PST) Received: from vampire.cryptek.gki.com by gki.com (4.1/SMI-4.1/ccg.7.2.91) id AA08911; Fri, 1 Dec 95 09:35:17 EST Received: by vampire.cryptek.gki.com (4.1/SMI-4.1) id AA00788; Fri, 1 Dec 95 09:35:18 EST Date: Fri, 1 Dec 95 09:35:18 EST From: williams@gki.com (Tim Williams) Message-Id: <9512011435.AA00788@vampire.cryptek.gki.com> To: firewalls@GreatCircle.COM Subject: Re: A1 Systems? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Mr Resino writes: > I'm not going to stick-up for Marcus. He's a big boy and can do that > for himself. The more inportant question is "What does it have to do > with Firewalls ?" A-1 features may be fine if you need them to > support your security policy. Do you need to implement them on your > firewall ? I don't know...it is your policy and firewall, isn't it ? I believe that your point about enforcing YOUR security policy is true. This is exactly why you should have a system with a high (defined in the risk assessment of your particular system) degree of assurance that it is doing YOUR policy and not doing something with or instead of YOUR security policy. With higher levels of assurance (B2 and above) there are extensive design reviews, testing (by third parites), and configuration management (no you can't change the code at any little whim of a programmer). These and other things that go into a higher assurance product allow those who have to sign their butts on the dotted line to go home at night and sleep. Having gone through the first network evaluation on a B2 system and going through 2 RAMP events on the product I know the riggors involved in first constructing and getting a system evaluated and then trying to keep the system up to date with current technology via the RAMP process. > The main point I see is that high security and assurance of that > security (2 different animal) has high overhead (system and > administrative). Many of us (at least I) would be happy to have a > high assurance C-2 file server and a relativly "snoop-free" net. A-1 > has a very limited customer base and an even lower interest base > (IMNSHO). Again this would depend on your level of risk. What are you protecting and what would it cost if the information was destroyed or given to your local bad guy (who ever that happes to be this week). If you were to look at a network system with respect to how it is accessed and who accesses the system, you can soon see places where it would be real nice to place a piece of hw/sw with a great level of assurance. And there will be other places on the network where things could (have to) be more relaxed. This all comes from really analyzing your particular situation. Note that someone else's solution may not fit your problem. Tim Williams williams@gki.com From firewalls-owner Fri Dec 1 08:04:55 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA28307 for firewalls-outgoing; Fri, 1 Dec 1995 07:13:45 -0800 (PST) Received: from gw2.att.com (gw2.att.com [192.20.239.134]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA28302 for ; Fri, 1 Dec 1995 07:13:39 -0800 (PST) Received: from vodka.sse.att.com (vodka.gc.att.com) by ig1.att.att.com id AA26412; Fri, 1 Dec 95 10:12:22 EST Message-Id: <9512011512.AA26412@ig1.att.att.com> From: mdr@vodka.sse.att.com Subject: Re: FW: A1 Systems? To: dalel@netcom.com (Dale Lancaster) Date: Fri, 1 Dec 1995 10:18:09 -0500 (EST) Cc: firewalls@greatcircle.com In-Reply-To: <199512010740.BAA24900@softserv.tcst.com> from "Dale Lancaster" at Dec 1, 95 01:40:33 am X-Mailer: ELM [version 2.4 PL23-upenn2.7] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Dale, > > First of all, I just recently joined the list and have really enjoyed the > threads of conversation. Its been educational to say the least. Please > keep up the good conversation and hopefully avoid the personal stuff. I'm enjoying it too. > > I have a general question related to Orange Book certification of systems. > In one of my past lifes I worked in and around this stuff (but am not an > expert what so ever) and I remembered that a MLS OS certified by the NCSC > could not/would not be ceritifed to support any networking access. At the You are correct, the evaluation refers only to the un-networked configuration. > time there was work on the networking security book (green, brown? forgot). > Anyway, if it truly was the case (I may have not intrepeted the facts > correctly at the time) that NCSC believed that a network connection would > basically make a MLS OS insecure, why should we assume that a firewall > running on top of a MLS is going to be much better off? Maybe I am behind I don't think that they meant that it would be insecure, but only that the evaluation was intended for the host. Networking was out-of-scope and no guarantees could be made. Host security will add a lot to a firewall. I think the better question to ask is "why would anyone want to run a firewall on an unsecured host?" > the times and they have since updated Orange Book to include networking or > the Green/Brown book now covers the issues. I follow the logic that more > must be better (more security features, mandatory access control, etc), but > all it takes is one hole and all the "more must be better" doesn't amount to > much. No, you've added another layer to the security controls. First they break the firewall, then they break the OS. But the OS is continually monitoring the firewall, and can hopefully detect when something goes wrong. The real question is "what kind of OS security do I need?" Everyone recomends something. Usually stripping it down, etc. Now you can take someone's best shot at securing an OS (maybe they even removed the compiler and did chroots) or you can go with a system that has undergone years of specialized development and modeling specifically for security. One that has undergone independent review. To me the Orange Book models, while dated, are clearly better than home-grown solutions. > > I also have to agree with the one person who fundamentally stated that to > get a certified OS in the A or B range would be almost useless when done > since the hardware and software is out of date with the current technology. > However, for the government, they tend to stick with older equipment anyway > due to budget constraints and becomes a lesser problem and for some sites, > security is far more important than having the latest and greatest. The > NCSC/Orange Book does not translate well into the commercial arena and I > don't believe they ever intended it to be useful or should keep pace with > commercial arenas. I have found many companies ask for C-2 or B-2 like > features, but did not require certification. I suspose the only thing they You generally have to choose between the vendor's latest offering, and the one that has gone thru the lenghty evaluation process. However, the latest offering is usually derived from some previous evaluated product and it has all of the security features. Also, the same developers are usually involved. > lose is that full assurance that an independent authority has done their > best to ensure that an OS is truly secure. At some point a company has to > cut off their paranoia for the sake of performance and money. For example, > a firewall running on a certified secure os might be considered more secure. > But if you are paranoid enough, you would want to know who certifies those > who certifies the OS (the NCSC). Are they experts? Are their methods > complete? Just because someone calls themselves experts doesn't make them > experts. Where do you stop, or do you? (of course this is a bit silly, but > it illustrates the point). Ultimately the solution is to have no connection > to the internet, but then you still have the more serious internal threats > to deal with. No one claims that the process is complete, but such an exhaustive (and exhausting) process will find bugs and the resulting OS will be more secure. I'm just arguing that *more* security is better. Independent review is a *good* thing. Why all of this extra effort? Because firewalls are so important. The security of your entire company may hinge on the security of that one host. Mark Riggins Secure System Engineering AT&T Bell Labs Usual Caveats apply From firewalls-owner Fri Dec 1 08:05:45 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA26359 for firewalls-outgoing; Fri, 1 Dec 1995 06:00:45 -0800 (PST) Received: from galil.austnsc.tandem.com (stocking.mpd.tandem.com [131.124.250.12]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id GAA26343 for ; Fri, 1 Dec 1995 06:00:35 -0800 (PST) Received: (from dreschs@localhost) by galil.austnsc.tandem.com (8.7.1/8.7.1) id IAA26826; Fri, 1 Dec 1995 08:03:14 -0600 (CST) Date: Fri, 1 Dec 1995 08:03:14 -0600 (CST) From: Sten Drescher Message-Id: <199512011403.IAA26826@galil.austnsc.tandem.com> To: CC: spencerj@dg-rtp.dg.com, mjr@iwi.com In-reply-to: "Marcus J. Ranum"'s message of Thu, 30 Nov 1995 18:09:36 -0500 (EST) Subject: Re: A1 Systems? References: <199511301818.SAA06837@splinter> <199511302309.SAA04333@switchblade.iwi.com> Cc: mjr@iwi.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk "Marcus J. Ranum" said: >> Now, to the Orange Book. The poster focused on features, but that is >> NOT the focus of the OB. The focus of the OB is ASSURANCE MJR> [...] >> However, I will be happy to discuss any supposed "irrelevance" of OB >> or ITSEC requirements to the commercial world. MJR> There's no need to -- you already explained (more tersely than I MJR> did) the problem with the orange book earlier on in your comments. MJR> It's not about features, it's about assurance. Assurance that the features work. MJR> Commercial computing is about features (represented as MJR> functionality) Therefore orange book is irrelevant to commercial MJR> computing. #ifdef HOLYWAR Given the success of Microsoft with Windows, you must be right. In commercial computing, it doesn't matter if the features work properly, just that there is an assertion that the features are there, and will work Real Soon Now. #endif /* HOLYWAR */ -- #include /* Sten Drescher */ To get my PGP public key, send me email with your public key and Subject: PGP key exchange Key fingerprint = 90 5F 1D FD A6 7C 84 5E A9 D3 90 16 B2 44 C4 F3 From firewalls-owner Fri Dec 1 08:09:47 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA28642 for firewalls-outgoing; Fri, 1 Dec 1995 07:37:52 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id HAA28624 for ; Fri, 1 Dec 1995 07:37:45 -0800 (PST) Message-Id: <199512011537.HAA28624@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA208662287; Sat, 2 Dec 1995 02:38:07 +1100 From: Darren Reed Subject: Re: port number to process id To: pm@ghdsign.dk (Peter Maersk-Moller) Date: Sat, 2 Dec 1995 02:38:07 +1100 (EDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <199512011052.LAA29818@soeren> from "Peter Maersk-Moller" at Dec 1, 95 11:52:19 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In some mail from Peter Maersk-Moller, sie said: > > > Hi Firewall list ! > > Is there a standard way/script/tool (must cover most un*ces) to find the > relation between IP port number in use and id of the process using the port ? Most lsof/ofiles type programs will do this. lsof, in particular... cheers, darren From firewalls-owner Fri Dec 1 08:10:05 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA25856 for firewalls-outgoing; Fri, 1 Dec 1995 05:41:36 -0800 (PST) Received: from cbisgate.cbis.com (cbisgate.cbis.com [155.90.248.205]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id FAA25851 for ; Fri, 1 Dec 1995 05:41:27 -0800 (PST) Received: from notes.cbis.com by cbisgate.cbis.com (5.x/SMI-SVR4) id AA01229; Fri, 1 Dec 1995 08:42:08 -0500 Received: by notes.cbis.com (IBM OS/2 SENDMAIL VERSION 1.3.14/2.12um) id AA4023; Fri, 01 Dec 95 08:41:56 -0500 Message-Id: <9512011341.AA4023@notes.cbis.com> Received: from CBIS with "Lotus Notes Mail Gateway for SMTP" id 826FC212C4EC726D85256285004494C0; Fri, 1 Dec 95 08:41:55 To: firewalls-digest From: Warren Moore Date: 1 Dec 95 8:38:31 Subject: Re: A1 Systems? X-Importance: High Mime-Version: 1.0 Content-Type: Text/Plain Sender: firewalls-owner@GreatCircle.COM Precedence: bulk My mailer thinks mjr said: > There's no need to -- you already explained (more tersely than >I did) the problem with the orange book earlier on in your comments. > > It's not about features, it's about assurance. > Commercial computing is about features (represented as functionality) > Therefore orange book is irrelevant to commercial computing. > With apologies to Marcus' cats (and my own), Isn't this like saying ...Owning Cats... Isn't about petting, it's about mousing. Feeling good is about petting (represented as purrs) Therefore owning cats is irrelevant to feeling good? Not even considering that you might be up to your fanny in mice, neither Marcus' or my logical construct is valid...because the initial premise is invalid on its face. A ne B, A eq C; D eq A; therefore A ne/or is irrelevant to C doesn't work unless A is *always* not equal to B, and A is *always* equal to C. Perhaps owning cats is irrelevant to feeling good, but it doesn't hurt. Actually, I partially agree with Marcus in that the Orange Book is *largely* irrelevant to commercial computing...but the last time I looked, *largely* doesn't mean *totally.* As a starting point, the rainbow series beats most things available to us. Of course, if confidentiality and assurance aren't part of the picture, why are we all wasting our time reading this list and sell ing security in one form or another? Warren S. Moore, CISSP Information Security Specialist Cincinnati Bell Information Systems Inc. From firewalls-owner Fri Dec 1 08:10:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA25331 for firewalls-outgoing; Fri, 1 Dec 1995 05:24:25 -0800 (PST) Received: from Mailer.Uni-Marburg.DE (papin.HRZ.Uni-Marburg.DE [137.248.1.8]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id FAA25271 for ; Fri, 1 Dec 1995 05:17:41 -0800 (PST) Received: from sumbi01.med.Uni-Marburg.DE by Mailer.Uni-Marburg.DE (AIX 3.2/UCB 5.64/20.07.94) id AA60175; Fri, 1 Dec 1995 14:17:44 +0100 Received: by med.uni-marburg.de (8.6.12/ADD-HUB-2.1) id OAA00354; Fri, 1 Dec 1995 14:16:33 +0100 Received: from post.med.uni-marburg.de(137.248.202.51) by sumbi01.med.uni-marburg.de via smap (V1.3) id sma000352; Fri Dec 1 14:16:18 1995 Received: from pcmbi60.med.uni-marburg.de (pcmbi60.med.uni-marburg.de [137.248.202.60]) by post.med.uni-marburg.de (8.6.11/8.6.9) with SMTP id PAA13134 for ; Fri, 1 Dec 1995 15:28:47 +0100 Message-Id: <199512011428.PAA13134@post.med.uni-marburg.de> From: "D.A. Meyer" To: firewalls@greatcircle.com Date: Fri, 1 Dec 1995 14:23:19 +0000 Subject: tn-gw crash Reply-To: meyerd@Mailer.Uni-Marburg.DE X-Mailer: Pegasus Mail/Windows (v1.22) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hi there, I need comments on a system crash caused by tn-gw, running on SunOS 4.1.3. Log listed below, the machine performed a reboot after the last messages. Could this be caused by a software error, a link library problems or by an attack? TIA Dirk +++++++++++++++++++++++++++++++++++++++Dec 1 11:19:11 marvin vmunix: BAD TRAP: cpu=0 type=9 rp=f0616d4c addr=20 mmu_fsr=326 rw=1 Dec 1 11:19:11 marvin vmunix: MMU sfsr=326: Invalid Address on supv data fetch at level 3 Dec 1 11:19:11 marvin vmunix: regs at f0616d4c: Dec 1 11:19:11 marvin vmunix: psr=409000c5 pc=f0020634 npc=f0020638 Dec 1 11:19:11 marvin vmunix: y: 40000000 g1: f0020628 g2: 8000000 g3: ffffff00 Dec 1 11:19:12 marvin vmunix: g4: 0 g5: f0617000 g6: 0 g7: 0 Dec 1 11:19:12 marvin vmunix: o0: f049b748 o1: fb043178 o2: ffbfffff o3: 20088001 Dec 1 11:19:12 marvin vmunix: o4: f0616fe0 o5: effff0f8 sp: f0616d98 ra: f0617000 Dec 1 11:19:12 marvin vmunix: pid 14924, `tn-gw': Data access exception Dec 1 11:19:12 marvin vmunix: kernel read fault at addr=0x20, pme=0x0 Dec 1 11:19:12 marvin vmunix: MMU sfsr=326: Invalid Address on supv data fetch at level 3 Dec 1 11:19:12 marvin vmunix: rp=0xf0616d4c, pc=0xf0020634, sp=0xf0616d98, psr=0x409000c5, context=0x31 Dec 1 11:19:12 marvin vmunix: g1-g7: f0020628, 8000000, ffffff00, 0, f0617000, 0, 0 Dec 1 11:19:12 marvin vmunix: Begin traceback... sp = f0616d98 Dec 1 11:19:12 marvin vmunix: Called from f00640cc, fp=f0616df8, args=0 ff64990c 0 1 f0616ebc 0 Dec 1 11:19:12 marvin vmunix: Called from f00669f8, fp=f0616e58, args=ff64990c 0 1 f0616ebc 3 ef7a6000 Dec 1 11:19:13 marvin vmunix: Called from f013fae0, fp=f0616ec0, args=f0616fe0 3b0 f01ba1d8 f01ba588 f04925d0 f0616fe0 Dec 1 11:19:13 marvin vmunix: Called from f0005cd0, fp=f0616f58, args=f0617000 f0616fb4 f0616fe0 f0617000 f0617000 f0616fb4 Dec 1 11:19:13 marvin vmunix: Called from 6d74, fp=effff430, args=0 0 1 effff8ac effff4a0 168ec Dec 1 11:19:13 marvin vmunix: End traceback... Dec 1 11:19:13 marvin vmunix: panic on cpu 0: Data access exception Dec 1 11:19:13 marvin vmunix: syncing file systems... done Dec 1 11:19:13 marvin vmunix: 01361 low-memory static kernel pages Dec 1 11:19:13 marvin vmunix: 00455 additional static and sysmap kernel pages Dec 1 11:19:13 marvin vmunix: SuperSPARC/SuperCache: PAC ENABLED Dec 1 11:19:13 marvin vmunix: SunOS Release 4.1.3_U1 (GENERIC) #1: Wed Oct 13 17:50:47 PDT 1993 Dec 1 11:19:13 marvin vmunix: Copyright (c) 1983-1993, Sun Microsystems, Inc. Dec 1 11:19:13 marvin vmunix: cpu = SUNW,SPARCstation-20 Dec 1 11:19:13 marvin vmunix: mod0 = TI,TMS390Z55 (mid = 8) Dec 1 11:19:13 marvin vmunix: mod1 = TI,TMS390Z55 (mid = 10) Dec 1 11:19:14 marvin vmunix: mem = 65052K (0x3f87000) Dec 1 11:19:14 marvin vmunix: avail mem = 61014016 Dec 1 11:19:14 marvin vmunix: cpu0 at Mbus 0x8 0x224000 Dec 1 11:19:14 marvin vmunix: cpu2 at Mbus 0xa 0x22c000 Dec 1 11:19:14 marvin vmunix: entering multiprocessor mode Dec 1 11:19:14 marvin vmunix: Ethernet address = 8:0:20:72:8b:c7 Dec 1 11:19:14 marvin vmunix: espdma0 at SBus slot f 0x400000 Dec 1 11:19:14 marvin vmunix: esp0 at SBus slot f 0x800000 pri 4 (onboard) Dec 1 11:19:14 marvin vmunix: sd0 at esp0 target 3 lun 0 Dec 1 11:19:14 marvin vmunix: sd0: Dec 1 11:19:14 marvin vmunix: sd1 at esp0 target 1 lun 0 Dec 1 11:19:14 marvin vmunix: sd1: Dec 1 11:19:14 marvin vmunix: ledma0 at SBus slot f 0x400010 Dec 1 11:19:14 marvin vmunix: le0 at SBus slot f 0xc00000 pri 6 (onboard) Dec 1 11:19:15 marvin vmunix: SUNW,bpp0 at SBus slot f 0x4800000 pri 3 (sbus level 2) Dec 1 11:19:15 marvin vmunix: SUNW,DBRIe0 at SBus slot e 0x10000 pri 9 (sbus level 5) Dec 1 11:19:15 marvin vmunix: dma0 at SBus slot 1 0x81000 Dec 1 11:19:15 marvin vmunix: esp1 at SBus slot 1 0x80000 pri 5 (sbus level 3) Dec 1 11:19:15 marvin vmunix: st4 at esp1 target 4 lun 0 Dec 1 11:19:15 marvin vmunix: st4: Dec 1 11:19:15 marvin vmunix: lebuffer0 at SBus slot 1 0x40000 Dec 1 11:19:15 marvin vmunix: le1 at SBus slot 1 0x60000 pri 7 (sbus level 4) Dec 1 11:19:15 marvin vmunix: cgsix0 at SBus slot 2 0x0 pri 9 (sbus level 5) Dec 1 11:19:15 marvin vmunix: cgsix0: screen 1152x900, single buffered, 1M mappable, rev 11 Dec 1 11:19:15 marvin vmunix: zs0 at obio 0x100000 pri 12 (onboard) Dec 1 11:19:15 marvin vmunix: zs1 at obio 0x0 pri 12 (onboard) Dec 1 11:19:16 marvin vmunix: SUNW,fdtwo0 at obio 0x700000 pri 11 (onboard) Dec 1 11:19:16 marvin vmunix: MMCODEC: manufacturer id 1, rev 2 Dec 1 11:19:16 marvin vmunix: root on sd0a fstype 4.2 Dec 1 11:19:16 marvin vmunix: swap on sd0b fstype spec size 66024K Dec 1 11:19:16 marvin vmunix: dump on sd0b fstype spec size 66012K Dec 1 11:19:16 marvin vmunix: le0: Twisted Pair Ethernet Dec 1 11:19:16 marvin vmunix: syncing file systems... SuperSPARC/SuperCache: PAC ENABLED Dec 1 11:19:17 marvin vmunix: SunOS Release 4.1.3_U1 (GENERIC) #1: Wed Oct 13 17:50:47 PDT 1993 Dec 1 11:19:17 marvin vmunix: Copyright (c) 1983-1993, Sun Microsystems, Inc. Dec 1 11:19:17 marvin vmunix: cpu = SUNW,SPARCstation-20 Dec 1 11:19:17 marvin vmunix: mod0 = TI,TMS390Z55 (mid = 8) Dec 1 11:19:17 marvin vmunix: mod1 = TI,TMS390Z55 (mid = 10) Dec 1 11:19:17 marvin vmunix: mem = 65052K (0x3f87000) ----------------------------------------------------------------- Dirk A. Meyer meyerd@mailer.uni-marburg.de Klinikum der Philipps-Universitaet Marburg Tel.xx49-6421-28-6291 Med. Informatik Fax.-------------8921 Bunsenstr. 3 D-35033 Marburg/Lahn ----------------------------------------------------------------- From firewalls-owner Fri Dec 1 10:29:57 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA29883 for firewalls-outgoing; Fri, 1 Dec 1995 09:22:38 -0800 (PST) Received: from E-MAIL.COM (e-mail.com [199.171.26.5]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA29878 for ; Fri, 1 Dec 1995 09:22:34 -0800 (PST) From: degheyndt-solvay@e-mail.com Message-Id: <199512011722.JAA29878@miles.greatcircle.com> Received: from e-mail by E-MAIL.COM (IBM VM SMTP V2R3) with BSMTP id 3653; Fri, 01 Dec 95 12:23:11 EST Date: Fri, 01 Dec 1995 12:23:13 EST To: firewalls@GreatCircle.COM MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: The WinWhatWhere freeware Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hello everybody, I'm looking for a shareware that is more or less (read more 'less' than 'more') related to the topics of this newsgroup. "WinWhatWhere" is a Windows utility ment to audit a shared Win 3.X workstation against intruders and unauthorised use. It is a detection-only tool. Thanks a lot. Dr. Jean-Jacques DE GHEYNDT Solvay S.A. - DSI-T&S Rue du Prince ALBERT, 33 B-1050 Brussels BELGIUM E-mail : degheyndt-solvay@e-mail.com Extra X400 information begins: Originator Name: JEAN-JACQUES DEGHEYNDT Org Units: HPDESK : BXLDSI : 00 Organisation: XLX400HP Domain: BE/RTT/SOLVAY Node.Userid: IBMX400.164956 Message Id: 9533518070400 PXLDSI1.HP.SOLVAY Importance: Normal Sent by Name: JEAN-JACQUES DEGHEYNDT Org Units: HPDESK : BXLDSI : 00 Organisation: XLX400HP Domain: BE/RTT/SOLVAY Node.Userid: IBMX400.164956 Subject: The WinWhatWhere freeware Recipients Name: INTERNET INTERNET Domain: GB/IBMX400/IBMMAIL Node.Userid: IBMMAIL.INTERNET From firewalls-owner Fri Dec 1 10:54:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA00494 for firewalls-outgoing; Fri, 1 Dec 1995 09:50:00 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA00489 for ; Fri, 1 Dec 1995 09:49:44 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id LAA18356; Fri, 1 Dec 1995 11:50:35 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id LAA18351; Fri, 1 Dec 1995 11:50:33 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id LAA04811; Fri, 1 Dec 1995 11:49:49 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id LAA18890; Fri, 1 Dec 1995 11:49:50 -0600 Date: Fri, 1 Dec 1995 11:49:50 -0600 From: Rick Smith Message-Id: <199512011749.LAA18890@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, goertzek@wangfed.com Subject: Re: A1 Systems? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk "K Goertzel" writes about SCC and A1: >The SCC LOCK platform was "designed to A1 level criteria" or some >such. However, recent scuttlebutt is that it was pulled out of >evaluation, probably because SCC is now frantically busy redesigning >their system from the ground up. What has happened is rather more interesting than that. We traded NCSC evaluation for a practical approach to high security assurance. We chose to do the formal assurance instead of following a famously flawed process and skipping a few steps. Both LOCK and SNS have formal security policy models, top level specifications, formal proofs, covert channel analyses, the whole A1 nine yards. The only difference is that we've reorganized the development process to try to build high assurance products in real time. In other words, build something that doesn't combine high assurance with obsolescence. > TIS and Wang Federal (formerly HFSI, formerly Honeywell Federal > Systems) have taken a more pragmatic approach to the problem. Being truly practical depends on what you intend to practice. > Given the functionality of an A1 system and the functionality of a > B3 system are *identical*, we decided the added documentation/ > mathematical proofs required to attain the A1 evaluation were not > worth the extra effort and cost, Keep in mind *why* you are doing B3 as opposed to B1 -- it's certainly not for the "security features" which really don't do much good for guards or firewalls. It's the *assurance* requirements of B3 that make the difference: the formal specifications, the extra testing, the architectural requirements, and so on. Assurance is important because it FINDS FLAWS. And when it doesn't find flaws, it provides evidence that the security behavior will function as expected. B3 is great because it makes you look at the security requirements and design in a rigorous fashion. B3 is a bummer because it comes so close to A1, then falls short. A few years back I reviewed faults detected during the formal assurance work on the LOCK program. Approximately a fourth were found while doing the proofs -- the step skipped by B3. So you lose that chunk of assurance and have to hope the bugs you miss aren't going to hurt too badly. Rick. smith@sctc.com secure computing corporation From firewalls-owner Fri Dec 1 11:19:52 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA29937 for firewalls-outgoing; Fri, 1 Dec 1995 09:27:04 -0800 (PST) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA29932 for ; Fri, 1 Dec 1995 09:27:01 -0800 (PST) Received: by mycroft.GreatCircle.COM (8.6.10/SMI-4.1/Brent-950602) id JAA18690; Fri, 1 Dec 1995 09:27:00 -0800 Received: from beach.sctc.com(192.55.214.50) by mycroft via smap (V1.3mjr) id sma018688; Fri Dec 1 09:26:50 1995 Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id LAA17661 for ; Fri, 1 Dec 1995 11:28:43 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id LAA17160; Fri, 1 Dec 1995 11:08:00 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id LAA04203; Fri, 1 Dec 1995 11:07:17 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id LAA17573; Fri, 1 Dec 1995 11:07:18 -0600 Date: Fri, 1 Dec 1995 11:07:18 -0600 From: Rick Smith Message-Id: <199512011707.LAA17573@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, jeromie@garrison.com Subject: Re: chroot/setuid vs type enforcement Sender: firewalls-owner@GreatCircle.COM Precedence: bulk jeromie@garrison.com asks about Marcus' kernel hacks: > I am interested in finding out if the process, that is running >inside of the chroot() system call, that marcus has hacked/patched, >would still be vulernable to attack subversion. Does this mean that a >chroot'ed environment is no longer vulerable to subversion via buffer >overflows? (IE: In stockwell's example he is worred about the process >escaping from the chroot'ed environment.) Is this no longer a >concern? I have a fundamental distrust of chroot() because it's a band-aid. It is not designed to control access to system resources in a general manner -- it does it through sleight of hand by hiding a crucial piece of information needed to access the rest of the system. Thus, if the information is visible by some other means, or if there are other available system resources to hack (like the network services that Marcus is blocking) then you're dead again. Another problem, which is held by most alternatives that Marcus noted in recent posts, is that correct behavior is in the hands of the applications software. If the applications software goofs, the protections are GONE. The underlying OS, whether it's a homespun Unix kernel or a TCSEC evaluated platform, can't step in and help. The application was responsible for setting up permissions and if it goofs there's no way to tell good accesses from bad ones. Type Enforcement has its domain and type tables that specify what accesses are supposed to be allowed and even a few that are considered especially obnoxious, as well as all the others that aren't allowed. These tables are tailored to the applications being used as part of the security engineering of those applications. The tables *can't* be changed while the system is in normal operation and their management is completely separate from all site oriented administrative activities. So, it's *not* just another form of chroot(), nor another form of Unix of VMS ACLs, which get messed up constantly, either by administrative accident or by an attacker. Rick. smith@sctc.com secure computing corporation From firewalls-owner Fri Dec 1 11:24:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA29825 for firewalls-outgoing; Fri, 1 Dec 1995 09:17:04 -0800 (PST) Received: from intex.intex.net (intex.intex.net [204.255.96.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA29810 for ; Fri, 1 Dec 1995 09:16:58 -0800 (PST) Received: from dialupb056.intex.net (dialupb056.intex.net [204.255.103.56]) by intex.intex.net (8.6.12/4.1.4) with SMTP id LAA23957; Fri, 1 Dec 1995 11:17:38 -0600 Message-Id: <199512011717.LAA23957@intex.intex.net> X-Sender: lpierce@intex.net X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 Dec 1995 11:17:01 -0600 To: Eric Vanuska , firewalls@GreatCircle.COM From: lpierce@intex.net (S. Lane Pierce) Subject: Re: is a second filter router worthwhile? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 10:14 AM 11/29/95 -0800, Eric Vanuska wrote: >Hello again, Hi >Last week I posted a query about TIS. Since I did not receive any >responses, I'm going to re-state my question. > >We want to protect our DMZ from our internal user community as well >as provide a "third layer of protection" from the users on the internet. >We have: > Internet -- Filter ---DMZ w/ TIS proxy -- Filter --- Internal Net > Router #1 server Router #2 > >The question boils down to this, does adding a second filtering router >provide any significant protection from crackers on the internet? First and formost, it will prevent the cr/hacker from being able to monitor traffic on the internal net if/when the proxy server is cracked. Keep in mind though that any protection you get is what you have programmed your filters for. >Because we are using TIS, the filters from our DMZ to our internal net >are very, very wide. In my eyes, this reduces the effectiveness of the >second filtering router to practically nothing. Although the second >router does protect our DMZ from our internal users quite nicely. > >I am assuming that an internet based cr/hacker is somehow able to gain >access to our TIS proxy server. (Yes I know this a big assumption, >but I am doing my best to be paranoid :)) Once that happens, allowing >the proxy server to initiate a TCP connection (w/ port > 1023) to any >one of our TIS clients is a bad thing. If you want to see which ports >I've opened up, please see original email below. > >In response, my crime-fighting-partner says, "...you're full of crap...". >Specifically he says: > 1. Since, we already have a filtering router and proxy servers, > how can a cr/hacker gain access to our proxy server? Tell your crime-fighting-partner to get his head out of the sand. Are you running syslog on the proxy server? Have you made all latest patches to TIS, the OS, etc...? > 2. So what if the proxy server can create a TCP connetion to > our clients. Unless the clients have an application that is listening > to these high number ports, what's the harm? > > >So what do all think? Am I being overly paranoid? Is it just about ^^^^^^^^^^^^^^^^^^^^^^^^^^ On this list!? Nah. ;-> >impossible that a cr/hacker can gain access to our proxy server, by >virute of the fact that it is protected by a filtering router, etc? >Is the second filtering router just protecting our DMZ from our >internal user community and nothing else? Is all this just window >dressing? > >Thanks, ericv Best of luck to you ericv. S. Lane Pierce lpierce@intex.net From firewalls-owner Fri Dec 1 11:54:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA00970 for firewalls-outgoing; Fri, 1 Dec 1995 10:08:46 -0800 (PST) Received: from Mailer.Uni-Marburg.DE (papin.HRZ.Uni-Marburg.DE [137.248.1.8]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA00865 for ; Fri, 1 Dec 1995 10:04:54 -0800 (PST) Received: from sumbi01.med.Uni-Marburg.DE by Mailer.Uni-Marburg.DE (AIX 3.2/UCB 5.64/20.07.94) id AA60175; Fri, 1 Dec 1995 14:17:44 +0100 Received: by med.uni-marburg.de (8.6.12/ADD-HUB-2.1) id OAA00354; Fri, 1 Dec 1995 14:16:33 +0100 Received: from post.med.uni-marburg.de(137.248.202.51) by sumbi01.med.uni-marburg.de via smap (V1.3) id sma000352; Fri Dec 1 14:16:18 1995 Received: from pcmbi60.med.uni-marburg.de (pcmbi60.med.uni-marburg.de [137.248.202.60]) by post.med.uni-marburg.de (8.6.11/8.6.9) with SMTP id PAA13134 for ; Fri, 1 Dec 1995 15:28:47 +0100 Message-Id: <199512011428.PAA13134@post.med.uni-marburg.de> From: "D.A. Meyer" To: firewalls@greatcircle.com Date: Fri, 1 Dec 1995 14:23:19 +0000 Subject: tn-gw crash Reply-To: meyerd@Mailer.Uni-Marburg.DE X-Mailer: Pegasus Mail/Windows (v1.22) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hi there, I need comments on a system crash caused by tn-gw, running on SunOS 4.1.3. Log listed below, the machine performed a reboot after the last messages. Could this be caused by a software error, a link library problems or by an attack? TIA Dirk +++++++++++++++++++++++++++++++++++++++Dec 1 11:19:11 marvin vmunix: BAD TRAP: cpu=0 type=9 rp=f0616d4c addr=20 mmu_fsr=326 rw=1 Dec 1 11:19:11 marvin vmunix: MMU sfsr=326: Invalid Address on supv data fetch at level 3 Dec 1 11:19:11 marvin vmunix: regs at f0616d4c: Dec 1 11:19:11 marvin vmunix: psr=409000c5 pc=f0020634 npc=f0020638 Dec 1 11:19:11 marvin vmunix: y: 40000000 g1: f0020628 g2: 8000000 g3: ffffff00 Dec 1 11:19:12 marvin vmunix: g4: 0 g5: f0617000 g6: 0 g7: 0 Dec 1 11:19:12 marvin vmunix: o0: f049b748 o1: fb043178 o2: ffbfffff o3: 20088001 Dec 1 11:19:12 marvin vmunix: o4: f0616fe0 o5: effff0f8 sp: f0616d98 ra: f0617000 Dec 1 11:19:12 marvin vmunix: pid 14924, `tn-gw': Data access exception Dec 1 11:19:12 marvin vmunix: kernel read fault at addr=0x20, pme=0x0 Dec 1 11:19:12 marvin vmunix: MMU sfsr=326: Invalid Address on supv data fetch at level 3 Dec 1 11:19:12 marvin vmunix: rp=0xf0616d4c, pc=0xf0020634, sp=0xf0616d98, psr=0x409000c5, context=0x31 Dec 1 11:19:12 marvin vmunix: g1-g7: f0020628, 8000000, ffffff00, 0, f0617000, 0, 0 Dec 1 11:19:12 marvin vmunix: Begin traceback... sp = f0616d98 Dec 1 11:19:12 marvin vmunix: Called from f00640cc, fp=f0616df8, args=0 ff64990c 0 1 f0616ebc 0 Dec 1 11:19:12 marvin vmunix: Called from f00669f8, fp=f0616e58, args=ff64990c 0 1 f0616ebc 3 ef7a6000 Dec 1 11:19:13 marvin vmunix: Called from f013fae0, fp=f0616ec0, args=f0616fe0 3b0 f01ba1d8 f01ba588 f04925d0 f0616fe0 Dec 1 11:19:13 marvin vmunix: Called from f0005cd0, fp=f0616f58, args=f0617000 f0616fb4 f0616fe0 f0617000 f0617000 f0616fb4 Dec 1 11:19:13 marvin vmunix: Called from 6d74, fp=effff430, args=0 0 1 effff8ac effff4a0 168ec Dec 1 11:19:13 marvin vmunix: End traceback... Dec 1 11:19:13 marvin vmunix: panic on cpu 0: Data access exception Dec 1 11:19:13 marvin vmunix: syncing file systems... done Dec 1 11:19:13 marvin vmunix: 01361 low-memory static kernel pages Dec 1 11:19:13 marvin vmunix: 00455 additional static and sysmap kernel pages Dec 1 11:19:13 marvin vmunix: SuperSPARC/SuperCache: PAC ENABLED Dec 1 11:19:13 marvin vmunix: SunOS Release 4.1.3_U1 (GENERIC) #1: Wed Oct 13 17:50:47 PDT 1993 Dec 1 11:19:13 marvin vmunix: Copyright (c) 1983-1993, Sun Microsystems, Inc. Dec 1 11:19:13 marvin vmunix: cpu = SUNW,SPARCstation-20 Dec 1 11:19:13 marvin vmunix: mod0 = TI,TMS390Z55 (mid = 8) Dec 1 11:19:13 marvin vmunix: mod1 = TI,TMS390Z55 (mid = 10) Dec 1 11:19:14 marvin vmunix: mem = 65052K (0x3f87000) Dec 1 11:19:14 marvin vmunix: avail mem = 61014016 Dec 1 11:19:14 marvin vmunix: cpu0 at Mbus 0x8 0x224000 Dec 1 11:19:14 marvin vmunix: cpu2 at Mbus 0xa 0x22c000 Dec 1 11:19:14 marvin vmunix: entering multiprocessor mode Dec 1 11:19:14 marvin vmunix: Ethernet address = 8:0:20:72:8b:c7 Dec 1 11:19:14 marvin vmunix: espdma0 at SBus slot f 0x400000 Dec 1 11:19:14 marvin vmunix: esp0 at SBus slot f 0x800000 pri 4 (onboard) Dec 1 11:19:14 marvin vmunix: sd0 at esp0 target 3 lun 0 Dec 1 11:19:14 marvin vmunix: sd0: Dec 1 11:19:14 marvin vmunix: sd1 at esp0 target 1 lun 0 Dec 1 11:19:14 marvin vmunix: sd1: Dec 1 11:19:14 marvin vmunix: ledma0 at SBus slot f 0x400010 Dec 1 11:19:14 marvin vmunix: le0 at SBus slot f 0xc00000 pri 6 (onboard) Dec 1 11:19:15 marvin vmunix: SUNW,bpp0 at SBus slot f 0x4800000 pri 3 (sbus level 2) Dec 1 11:19:15 marvin vmunix: SUNW,DBRIe0 at SBus slot e 0x10000 pri 9 (sbus level 5) Dec 1 11:19:15 marvin vmunix: dma0 at SBus slot 1 0x81000 Dec 1 11:19:15 marvin vmunix: esp1 at SBus slot 1 0x80000 pri 5 (sbus level 3) Dec 1 11:19:15 marvin vmunix: st4 at esp1 target 4 lun 0 Dec 1 11:19:15 marvin vmunix: st4: Dec 1 11:19:15 marvin vmunix: lebuffer0 at SBus slot 1 0x40000 Dec 1 11:19:15 marvin vmunix: le1 at SBus slot 1 0x60000 pri 7 (sbus level 4) Dec 1 11:19:15 marvin vmunix: cgsix0 at SBus slot 2 0x0 pri 9 (sbus level 5) Dec 1 11:19:15 marvin vmunix: cgsix0: screen 1152x900, single buffered, 1M mappable, rev 11 Dec 1 11:19:15 marvin vmunix: zs0 at obio 0x100000 pri 12 (onboard) Dec 1 11:19:15 marvin vmunix: zs1 at obio 0x0 pri 12 (onboard) Dec 1 11:19:16 marvin vmunix: SUNW,fdtwo0 at obio 0x700000 pri 11 (onboard) Dec 1 11:19:16 marvin vmunix: MMCODEC: manufacturer id 1, rev 2 Dec 1 11:19:16 marvin vmunix: root on sd0a fstype 4.2 Dec 1 11:19:16 marvin vmunix: swap on sd0b fstype spec size 66024K Dec 1 11:19:16 marvin vmunix: dump on sd0b fstype spec size 66012K Dec 1 11:19:16 marvin vmunix: le0: Twisted Pair Ethernet Dec 1 11:19:16 marvin vmunix: syncing file systems... SuperSPARC/SuperCache: PAC ENABLED Dec 1 11:19:17 marvin vmunix: SunOS Release 4.1.3_U1 (GENERIC) #1: Wed Oct 13 17:50:47 PDT 1993 Dec 1 11:19:17 marvin vmunix: Copyright (c) 1983-1993, Sun Microsystems, Inc. Dec 1 11:19:17 marvin vmunix: cpu = SUNW,SPARCstation-20 Dec 1 11:19:17 marvin vmunix: mod0 = TI,TMS390Z55 (mid = 8) Dec 1 11:19:17 marvin vmunix: mod1 = TI,TMS390Z55 (mid = 10) Dec 1 11:19:17 marvin vmunix: mem = 65052K (0x3f87000) ----------------------------------------------------------------- Dirk A. Meyer meyerd@mailer.uni-marburg.de Klinikum der Philipps-Universitaet Marburg Tel.xx49-6421-28-6291 Med. Informatik Fax.-------------8921 Bunsenstr. 3 D-35033 Marburg/Lahn ----------------------------------------------------------------- From firewalls-owner Fri Dec 1 12:29:26 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA01746 for firewalls-outgoing; Fri, 1 Dec 1995 10:42:06 -0800 (PST) Received: from montag33.residence.gatech.edu (montag33.residence.gatech.edu [199.77.171.12]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA01741 for ; Fri, 1 Dec 1995 10:42:02 -0800 (PST) Received: (from brain21@localhost) by montag33.residence.gatech.edu (8.6.12/8.6.9) id NAA17620; Fri, 1 Dec 1995 13:41:59 -0500 Date: Fri, 1 Dec 1995 13:41:59 -0500 (EST) From: Brain21 To: firewalls@greatcircle.com Subject: Re: Remote Access Firewall In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > On Thu, 30 Nov 1995, Brain21 wrote: > > > On Wed, 29 Nov 1995, NELDA wrote: > > > > > > Well, ya did it again! No message, just blank email. Not even something > > attached. > > > > brain21 > > > > > > Course, was there a reason to broadcast this flame? > Hmm. Second letter I got on this. It was not really meant as a flame, for one. Just a notification. Second, I mailed it to the list by accident, and I apologize. At least it wasn't some huge long, quoted letter! :) In order to (hopefully) avoid future emails like this I am sending THIS to the list. Brain21 From firewalls-owner Fri Dec 1 13:42:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA01430 for firewalls-outgoing; Fri, 1 Dec 1995 10:27:34 -0800 (PST) Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id KAA01421 for ; Fri, 1 Dec 1995 10:27:27 -0800 (PST) Received: from svcs1.digex.net by relay2.UU.NET with SMTP id QQzsgg09793; Fri, 1 Dec 1995 11:35:37 -0500 (EST) Received: from GWFX1.sysorex.com (gwfx1.sysorex.com [204.192.18.20]) by svcs1.digex.net (8.6.12/8.6.12) with SMTP id LAA14380; Fri, 1 Dec 1995 11:31:34 -0500 Received: from ccMail by GWFX1.sysorex.com (SMTPLINK V2.10.08) id AA817846091; Fri, 01 Dec 95 11:27:53 EST Date: Fri, 01 Dec 95 11:27:53 EST From: "Dave Druitt" Message-Id: <9511018178.AA817846091@GWFX1.sysorex.com> To: mjr@iwi.com, firewalls@greatcircle.com, cssmith@deltacom.com (Christopher Smith) Subject: Re[2]: A1 Systems? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk question, but why don't we (the list -- whomever) come up with our definitions on system security. If I remember correctly, someone was complaining about the lack of firewalls standards, well, seems logical that we should start with a workable system security model first. Just a thought. > There are still orange book systems out there, and there >are still people working on them, but that's really part of the >government's typical inability to terminate an unsuccessful >program. > _________________________ What a great idea! A real set of security definitions based on real-world scenarios! This HAS to be a first... regards, Dave Druitt Senior Systems Engineer Sysorex Information Systems From firewalls-owner Fri Dec 1 13:51:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA01087 for firewalls-outgoing; Fri, 1 Dec 1995 10:14:51 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA01082 for ; Fri, 1 Dec 1995 10:14:30 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id MAA19126; Fri, 1 Dec 1995 12:16:09 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id MAA19122; Fri, 1 Dec 1995 12:16:09 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id MAA05393; Fri, 1 Dec 1995 12:15:24 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id MAA20233; Fri, 1 Dec 1995 12:15:25 -0600 Date: Fri, 1 Dec 1995 12:15:25 -0600 From: Rick Smith Message-Id: <199512011815.MAA20233@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, paulm@MR.Net Subject: Re: Firewall Selection Criteria Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Paul Merenbloom asks about firewall selection criteria: >What would you consider the top 5-10 issues? How does price >sensitivity (or lack thereof) affect your rankings / issues? On what >basis would (or have) you made your decisions (or guided others)? Here's a cut at some criteria: 1) Compatibility with current operational requirements. Keep in mind that requirements need to be traded off against security risks, and vice versa. You can't be a slave to today's protocols but you can't dismiss them either. 2) Ability to block attacks. Do they block current ones, and what is their strategy for handling future ones? 3) Ability to monitor what's going on and report trouble in a timely manner. Good records can help you identify emerging problems and document serious attacks. Rapid incident response puts people against the attacker -- humans are always better than machines. 4) Can the vendor provide convincing evidence that the product really works as claimed? That's "assurance" -- some vendors just do a bit of testing, others back their products with established development processes, configuration control, design analysis, and top it off with testing. Why buy from a garage shop? What about price? Well, look at what organizations spend for disaster recovery setups. Even the most expensive firewall system is cheaper. Rick. smith@sctc.com secure computing corporation From firewalls-owner Fri Dec 1 13:54:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA01872 for firewalls-outgoing; Fri, 1 Dec 1995 10:46:44 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA01845 for ; Fri, 1 Dec 1995 10:46:19 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id MAA20041; Fri, 1 Dec 1995 12:47:07 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id MAA20037; Fri, 1 Dec 1995 12:47:06 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id MAA06023; Fri, 1 Dec 1995 12:46:22 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id MAA21477; Fri, 1 Dec 1995 12:46:22 -0600 Date: Fri, 1 Dec 1995 12:46:22 -0600 From: Rick Smith Message-Id: <199512011846.MAA21477@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, mjr@iwi.com Subject: Quality Assurance (was: A1 Systems?) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Marcus quotes a posting: >>Now, to the Orange Book. The poster focused on features, but that is NOT >>the focus of the OB. The focus of the OB is ASSURANCE >[...] >>However, I will be happy to discuss any supposed "irrelevance" of OB or ITSEC >>requirements to the commercial world. Then Marcus says: > There's no need to -- you already explained (more tersely than >I did) the problem with the orange book earlier on in your comments. > It's not about features, it's about assurance. > Commercial computing is about features (represented as functionality) > Therefore orange book is irrelevant to commercial computing. Here at Secure Computing we're betting that you're wrong. That's why we're in the midst of ISO 9000 certification, why we produced a policy specification for Sidewinder, why we built a whole new security mechanism into Unix instead of pasting in some patches, why we track all bug reports to closure, why we run the system through a very controlled validation and release cycle, and even why we run the Challenge. People may cut corners by buying MS Word, bugs and all, but they'll pay extra for a security system system that's arguably safer than the competition. Not everyone will pay extra, but we believe in the long term customers will buy assured quality. Maybe someday we'll solve the mystery of making A1 commercial products. Meanwhile we still do the best we can. Rick. smith@sctc.com secure computing corporation From firewalls-owner Fri Dec 1 14:10:09 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA02570 for firewalls-outgoing; Fri, 1 Dec 1995 11:12:07 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA02556 for ; Fri, 1 Dec 1995 11:11:49 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id NAA20769; Fri, 1 Dec 1995 13:13:42 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id NAA20761; Fri, 1 Dec 1995 13:13:39 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id NAA06818; Fri, 1 Dec 1995 13:12:55 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id NAA22972; Fri, 1 Dec 1995 13:12:54 -0600 Date: Fri, 1 Dec 1995 13:12:54 -0600 From: Rick Smith Message-Id: <199512011912.NAA22972@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, pnh1rgr@mclo20.med.navy.mil Subject: Re: A1 Systems? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk "Bob Resino" writes: >The main point I see is that high security and assurance of that >security (2 different animal) has high overhead (system and >administrative). Many of us (at least I) would be happy to have a >high assurance C-2 file server and a relativly "snoop-free" net. A-1 >has a very limited customer base and an even lower interest base The critical "feature" difference between the C level systems and the B and A level systems is, of course, the mandatory access control. And that's *exactly* what you need if your system is going to be in harm's way, like a firewall protecting your site from the Internet. I don't think traditional MLS is the perfect answer, but the basic concept is sound -- there are some protections that *nobody* in the system should be messing with, especially when the system is running. And the system *must* have mechanisms to protect itself from serious attacks. That's what C2 systems don't have, and assurance won't make them any stronger. We put Type Enforcement into Sidewinder because it gives the mandatory protection a firewall needs, not what the Orange Book dictates. Levels of assurance come down to balancing cost against perceived risks. We do as much as we can afford to for Sidewinder given the nature of the market. We've even done portions of the high level security policy analysis that is the earmark of high assurance security systems. Every piece of analysis we do gives a better vision of the system's actual properties, and we just keep working at it. Rick. smith@sctc.com secure computing corporation From firewalls-owner Fri Dec 1 14:16:46 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA01518 for firewalls-outgoing; Fri, 1 Dec 1995 10:33:03 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA01513 for ; Fri, 1 Dec 1995 10:32:56 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id MAA19597; Fri, 1 Dec 1995 12:33:54 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id MAA19593; Fri, 1 Dec 1995 12:33:53 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id MAA05761; Fri, 1 Dec 1995 12:33:09 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id MAA20841; Fri, 1 Dec 1995 12:33:09 -0600 Date: Fri, 1 Dec 1995 12:33:09 -0600 From: Rick Smith Message-Id: <199512011833.MAA20841@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, leonard@geminisecure.com Subject: Re: FW: A1 Systems? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Leonard Miyata writes: >Were trying to show the world there is a use (and a need) for >multi-level secure trusted technology in the commercial world. It's about time you got here. Some time last year (I was probably arguing about covert channels with Padgett) I noted that the really neat thing about the firewalls world is that *finally* commercial sites need to enforce a mandatory data security boundary with a computing system. Now we just need to convince a few recalcitrant experts about the importance of high assurance techniques. >Now other companies have developed and fielded trusted boxes, but >their not using them for Firewalls applications. Since there is a need >for high Security network access, The Question that has to be asked is >"WHY ?" We don't put conventional Orange Book labels in Sidewinder because they enforce the wrong security policy. In fact, those lovely hierarchical labels that "trusted products" have spent so much effort on just don't work for firewalls. We ran into that really quickly on the SNS Mail Guard, which can *not* transfer data blindly in *either* direction. Of course, it won't let the Unclass guy read the Secret mail until it's examined and released. But it goes the other way, too. Just because the Secret guy is authorized to read Unclass data doesn't mean he gets direct access to it. The Unclass mail has to be examined and released, too. Thus, you *can't* just blindly throw software on a trusted platform and have a secure firewall. You *can* build a good firewall on a "trusted" platform, but it takes care and sophistication. Naturally, I think it's easier and more reliable to to do with Type Enforcement since TE gives you a finer degree of control over accesses. Rick. smith@sctc.com secure computing corporation From firewalls-owner Fri Dec 1 14:29:14 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA02947 for firewalls-outgoing; Fri, 1 Dec 1995 11:32:14 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA02942 for ; Fri, 1 Dec 1995 11:31:55 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id NAA21229; Fri, 1 Dec 1995 13:32:46 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id NAA21224; Fri, 1 Dec 1995 13:32:42 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id NAA07145; Fri, 1 Dec 1995 13:31:58 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id NAA23745; Fri, 1 Dec 1995 13:31:57 -0600 Date: Fri, 1 Dec 1995 13:31:57 -0600 From: Rick Smith Message-Id: <199512011931.NAA23745@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, goertzek@wangfed.com Subject: Re: A1 Systems? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk "K Goertzel" writes about trusted platforms: >I also deal frequently with the security/accreditation officers for >numerous U.S. and foreign government agencies, and in many cases their >policy is that they will not accept systems that have not been >evaluated. They simply are unwilling to assume the risk implied by >trusting the vendor's word alone that the alleged security mechanisms >on his system work exactly as documented, with no backdoors or other >vulnerabilities. In many of the cases I've come across, the use of trusted platforms is heavily driven by existing policy directives and not by a belief in the security of evaluated platforms. > The TCSEC/ITSEC approach to assuring system security >may be flawed, but I think it's better than trusting the INFOSEC >equivalent of a used car salesman, don't you? This argument doesn't work for firewalls. You end up trusting the vendor's word anyway. If the evaluation process actually certified the application (as it does with the SNS Mail Guard) then an evaluation might mean something. In practice, the trusted platforms only enforce the narrow expectations of the Orange Book. When a firewall on a "trusted platform" starts spewing data back and forth, the *unevaluated* firewall software is the only thing preserving your security. A talented and sophisticated development organization should be able to take a typical trusted platform and build a really secure firewall. But the security depends heavily on how well they benefit from the underlying TCB capabilities, and there are lots of ways to goof up. Rick. smith@sctc.com secure computing corporation From firewalls-owner Fri Dec 1 15:10:26 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA01323 for firewalls-outgoing; Fri, 1 Dec 1995 10:23:50 -0800 (PST) Received: from main.geminisecure.com (main.geminisecure.com [205.179.16.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA01313 for ; Fri, 1 Dec 1995 10:23:43 -0800 (PST) Received: (from leonard@localhost) by main.geminisecure.com (8.6.9/8.6.9) id KAA05653; Fri, 1 Dec 1995 10:18:03 -0800 Date: Fri, 1 Dec 1995 10:18:03 -0800 (PST) From: Leonard Miyata To: Dale Lancaster cc: firewalls@GreatCircle.COM Subject: Re: FW: A1 Systems? In-Reply-To: <199512010740.BAA24900@softserv.tcst.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Fri, 1 Dec 1995, Dale Lancaster wrote: > First of all, I just recently joined the list and have really enjoyed the > threads of conversation. Its been educational to say the least. Please > keep up the good conversation and hopefully avoid the personal stuff. > > I have a general question related to Orange Book certification of systems. > In one of my past lifes I worked in and around this stuff (but am not an > expert what so ever) and I remembered that a MLS OS certified by the NCSC > could not/would not be ceritifed to support any networking access. At the > time there was work on the networking security book (green, brown? forgot). > Anyway, if it truly was the case (I may have not intrepeted the facts > correctly at the time) that NCSC believed that a network connection would > basically make a MLS OS insecure, why should we assume that a firewall > running on top of a MLS is going to be much better off? Maybe I am behind > the times and they have since updated Orange Book to include networking or > the Green/Brown book now covers the issues. I follow the logic that more > must be better (more security features, mandatory access control, etc), but > all it takes is one hole and all the "more must be better" doesn't amount to > much. > :-) > dale > ============================================================================ > Dale Lancaster > TITAN SPECTRUM Technologies > Director of Marketing > dalel@netcom.com > (214) 423-6212 / (214) 423-6579 (Fax) > ============================================================================ Yes, it is debatable how much the TCSEC and the TNI applies to the modern distributed networking environment. But for Guard applications, the Orange Book and Red Book still apply The box that we have is classified as a M-1 componenet (but being a junior software engineer here, I'm not sure I comprehend the significance of the designation). But back to the point, our Guard does not deal in terms of people, it deals in terms of Data. The basic principle of a Guard is the controled release of information of Data from Sources of one Security/Integrity Level to another, following the security policy implied by the A-1, B-3, B-2, B-1 kernal. A Guard basicly takes blocks of Data from Multiple Single Level Ports, labels and cryptoseals them, and passes them to a Multi Level Secure port. Incoming Data blocks from the MLS port are then checked against the internal write up rules, as well as the appropriate seal and label checks and passed to the correct MSL Port. In the Case of a IP Guard, IP packets make a nice well defined block of Data, and the MLS (Internet) Port is considered untrusted... Leonard Miyata aka leonard@geminisecure.com GEMINI COMPUTERS INC. Web page http://www.geminisecure.com From firewalls-owner Fri Dec 1 15:13:06 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA04763 for firewalls-outgoing; Fri, 1 Dec 1995 12:22:32 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA04733 for ; Fri, 1 Dec 1995 12:22:06 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id OAA23189 for ; Fri, 1 Dec 1995 14:24:07 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id OAA23185 for ; Fri, 1 Dec 1995 14:24:06 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id OAA08741; Fri, 1 Dec 1995 14:23:20 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id OAA26500; Fri, 1 Dec 1995 14:23:20 -0600 Date: Fri, 1 Dec 1995 14:23:20 -0600 From: Rick Smith Message-Id: <199512012023.OAA26500@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com Subject: Re: chroot/setuid vs type enforcement Sender: firewalls-owner@GreatCircle.COM Precedence: bulk jeromie@garrison.com writes: >> As far as being able to remove system calls from accessibility, I would >>like to hear about if any firewalls have done this. Removing the system calls >>from accessibility would limit potential vulerabilities. And, bless him, Marcus responds with a box of band aids: > It's not hard to do; you simply comment them out of the kernel >or appropriately modify the kernel. I staunchly refuse to accept that >these things are rocket science, or even very difficult; the kernel >is just a program and if you are smart enough to use a system you can >get source for then it's easy to fix. [fix details omitted] About twenty years ago a pal got a job at one of the neighborhood minicomputer manufacturers (there was one on every block back then) and got into an argument with his boss, because he wanted to maintain his own copy of the OS so he could fix "a few minor things" that interfered with how he though things should work. Now, I didn't have much experience with developing and maintaining a large, complex software product back then, but even then I correctly predicted the boss would throw him out of his office. Sure, Secure Computing has created its own version of Unix. But this is not, repeat *not*, a casual exercise. I agree it's not rocket science -- rocket science is much easier than reliably manipulating large software systems. The big difference is that the software rarely distributes you across multiple counties when it blows up. Regarding Marcus' specific example: chroot() is a pitiful thing. I dislike any security mechanism that relies on an application to set protections up correctly anyway. My readings also tell me that it has subtly different properties on different Unix systems. So, a properly chroot'ed program for one Unix might in fact be vulnerable on a different one. And the list goes on. > The *TRICK* is implementing the RIGHT code in the RIGHT >place. For this example, if I put it in socket() - what about other >forms of IPC? See - I'd need to be darn careful to cover all the >angles. That's nothing to do with the formal properties of my >protection model; that's a simple matter of Getting The Code Right >and Damn The Formal Handwaving. How does the poor sap know if the code is right? This has *everything* to do with properties of the protection model, A decent protection model can tell him if the kernel interface change is likely to be correct or even adequate for the problem at hand. Othewise you're just waiting for problems to emerge before fixing them-- chasing the problems instead of getting in front of them. People hate the Formal Handwaving because real systems are usually too ugly and misshapen to make it worthwhile. And computer graphics was difficult for toddlers before KidPix arrived. If the Unix kernel interface implemented an adequate protection model for what we're doing (it doesn't, which is why we put in TE) then the Formal Handwaving would provide an obvious benefit. There's also the whole question of playing fast and loose with the Unix kernel interface -- what else breaks when you allegedly fix this alleged security hole? Be sure to fix your kernel interface validation suite when you change the kernel. And be sure your development team all get updated kernel interface specs, and that they're WARNED that their previous knowledge about the interface are no longer true. > This whole game is about being REAL careful about your code. >Whether it's code in the kernel or code in user space, it's just >code. Because someone's waved the orange-book over the hacks they >made to the kernel doesn't make them any fancier than the kind of >hackery I described above (but for sure they're better documented!) The Orange Book was written after security people spent several years discovering that it's not enough to be careful about the code, not even "REAL careful." Sure, it's obsolete in its current form and implementation, but don't toss the baby with the bathwater. If you can analyze something, you can learn something. The analysis doesn't give you the Whole Truth, but it's valuable when it finds flaws. And it does. Rick. smith@sctc.com secure computing corporation From firewalls-owner Fri Dec 1 15:24:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA10983 for firewalls-outgoing; Fri, 1 Dec 1995 15:06:55 -0800 (PST) Received: from dcc.com (ns.profitsolutions.com [204.147.95.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id PAA10978 for ; Fri, 1 Dec 1995 15:06:51 -0800 (PST) Received: by gateway.dcc.com id <79391>; Fri, 1 Dec 1995 17:28:32 -0600 From: "Moubray, Steve" To: "'firewalls@greatcircle.com'" Subject: RE: Firewall Selection Criteria Date: Fri, 1 Dec 1995 19:04:00 -0600 X-Mailer: Microsoft Mail V3.0 Message-Id: <95Dec1.172832cst.79391@gateway.dcc.com> Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >From: Paul Merenbloom >Date: Wed, 29 Nov 1995 16:30:42 -0600 >Subject: Firewall Selection Criteria > >Hello All, > >Since everyone seems to have gotten in their two-cents about the = >DataComm F/W analysis, good, bad, ugly or simply indifferent how about a = >few go-rounds on what criteria users (eg buyers) _should look for or = >require_ when evaluating / selecting F/W product(s) for their = >environments. > >Clearly there are first-cut deliniations (sp) between packet filters, = >application gateways and app. gateways that live on top of trusted = >operating systems. Finding who offers what isn't all that challenging = >(pardon the pun) but I've had several conversations with vendors and = >users who can't seem to identify _why_ one should buy (or consider) one = >product over another. > >What would you consider the top 5-10 issues? How does price = >sensitivity (or lack thereof) affect your rankings / issues? On what = >basis would (or have) you made your decisions (or guided others)? > >Anyone care to opine? > > -- plm > IMHO - My top 3. Criteria # 1 is your needs. I often talk to people interested in features and marketing. The major players in the business are "leap frogging" each other in functionality. Define your short, mid and long term needs. The long term needs change often so focus mostly on the short and mid term needs. If one manufacturer has a feature that you might need in 1 or 2 years, chances are that most firewalls will have that same feature by then. Basically don't buy just for certain features if you are not going to use them. Also take a look at everything that might need a firewall. We generally think about firewalls for only Internet access but what about the other networks that are connected? Take a look at the database company or the payroll vendor or who ever. Criteria # 2 is support. Make sure that you have the staff and vendors to support the system. A firewall won't do you any good if you can't manage and support it. If you have good HP/UX support, look for something on HP/UX or if you have good BSD support look for something like that. If you don't have any UNIX support look for something that has a good interface and requires limited (or no) command line configuration. Criteria # 3 reputation and staying power. Many firewall vendors have come and gone in the last year but a some have been around for a few years (I know I'll take some heat for this one). I assume that if a vendor has been doing firewalls for a couple of years and is financially strong that they will probably be around for a few more years. I'm sure that a few new companies will do quite well but I like a good track record. I have a list that I use when looking for features from vendors and it has 6 names on it. These have all been very helpful and all but one has been doing commercial firewalls for a few years. The one that hasn't is local and been extra helpful (local means they get extra support points). A few other things should be considered but these are the top 3 in my book. I have run across companies that haven't done all three and regretted it. Remember - you have to buy it, support it and live with it. Good luck. ------------------------------------- Steve Moubray DCC, Inc. smoubray@dcc.com http://www.dcc.com/ From firewalls-owner Fri Dec 1 15:25:35 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA05925 for firewalls-outgoing; Fri, 1 Dec 1995 12:54:10 -0800 (PST) Received: from tuna.wang.com (tuna.wang.com [150.124.136.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA05919 for ; Fri, 1 Dec 1995 12:54:06 -0800 (PST) Received: from mail.wangfed.com (ns.wangfed.com [159.94.10.19]) by tuna.wang.com (8.6.12/8.6.12tf1) with SMTP id PAA05854; Fri, 1 Dec 1995 15:54:55 -0500 Received: from [159.94.10.15] by mail.wangfed.com (1.37.109.4/A.09.00a) id AA25823; Fri, 1 Dec 95 15:47:18 -0600 Received: from [159.94.14.48] by hfsi (BULL 5.61++/B.O.S 02.01) id AA01855; Fri, 1 Dec 95 15:44:49 -0500 Date: Fri, 1 Dec 95 15:44:49 -0500 Message-Id: <9512012044.AA01855@hfsi> From: "K Goertzel" Reply-To: "K Goertzel" To: firewalls@greatcircle.com, smith@sctc.com Subject: Re: A1 Systems? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In message <199512011931.NAA23745@shade.sctc.com> Rick Smith writes: > This argument doesn't work for firewalls. You end up trusting the > vendor's word anyway. Not strictly true in the military and other parts of the goverment, where they have something called the system accreditor whose job it is to at least validate the vendor's claims. That certain civilian agencies and less enlightened members of private industry are either too naive, too cheap, or too lazy to do the same means they only get what they deserve when the firewall fails to protect them as advertised. Karen Goertzel Manager, International Programmes and Special Projects Secure Systems and Services Operation Wang Federal, Inc. 7900 Westpark Drive - MS 700 McLean, Virginia 22102-4299 TEL: 703-827 3914 FAX: 703-827 3161 Internet: goertzek@wangfed.com +-----------------------------------------+ | Human history becomes more and more a | | race between education and catastrophe. | | - H.G. Wells | +-----------------------------------------+ From firewalls-owner Fri Dec 1 15:25:36 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA05827 for firewalls-outgoing; Fri, 1 Dec 1995 12:50:50 -0800 (PST) Received: from tuna.wang.com (tuna.wang.com [150.124.136.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA05815 for ; Fri, 1 Dec 1995 12:50:45 -0800 (PST) Received: from mail.wangfed.com (ns.wangfed.com [159.94.10.19]) by tuna.wang.com (8.6.12/8.6.12tf1) with SMTP id PAA05728; Fri, 1 Dec 1995 15:51:35 -0500 Received: from [159.94.10.15] by mail.wangfed.com (1.37.109.4/A.09.00a) id AA25746; Fri, 1 Dec 95 15:43:57 -0600 Received: from [159.94.14.48] by hfsi (BULL 5.61++/B.O.S 02.01) id AA01824; Fri, 1 Dec 95 15:41:27 -0500 Date: Fri, 1 Dec 95 15:41:27 -0500 Message-Id: <9512012041.AA01824@hfsi> From: "K Goertzel" Reply-To: "K Goertzel" To: firewalls@greatcircle.com, smith@sctc.com Subject: Re: A1 Systems? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In message <199512011749.LAA18890@shade.sctc.com> Rick Smith writes: > Both LOCK and SNS have formal security policy models, top level > specifications, formal proofs, covert channel analyses, the whole A1 > nine yards. The only difference is that we've reorganized the > development process to try to build high assurance products in real > time. In other words, build something that doesn't combine high > assurance with obsolescence. Which means I, as a potential customer, am still stuck with the problem of having to trust the car salesman's word that the car will run. Of course, I may also question the competence of NCSC's evaluators, but at least they have no vested interest in a product passing or failing evaluation (well, except in one case that shall remain nameless where they have invested something like $20M in the product's development; it's probably a good thing that that product isn't going to go through a TCSEC evaluation, given the result would be highly suspect given NSA's interest in seeing it pass). Karen Goertzel Manager, International Programmes and Special Projects Secure Systems and Services Operation Wang Federal, Inc. 7900 Westpark Drive - MS 700 McLean, Virginia 22102-4299 TEL: 703-827 3914 FAX: 703-827 3161 Internet: goertzek@wangfed.com +-----------------------------------------+ | Human history becomes more and more a | | race between education and catastrophe. | | - H.G. Wells | +-----------------------------------------+ From firewalls-owner Fri Dec 1 15:31:18 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA05592 for firewalls-outgoing; Fri, 1 Dec 1995 12:43:10 -0800 (PST) Received: from tuna.wang.com (tuna.wang.com [150.124.136.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA05566 for ; Fri, 1 Dec 1995 12:42:56 -0800 (PST) Received: from mail.wangfed.com (ns.wangfed.com [159.94.10.19]) by tuna.wang.com (8.6.12/8.6.12tf1) with SMTP id PAA05350; Fri, 1 Dec 1995 15:43:12 -0500 Received: from [159.94.10.15] by mail.wangfed.com (1.37.109.4/A.09.00a) id AA25601; Fri, 1 Dec 95 15:35:35 -0600 Received: from [159.94.14.48] by hfsi (BULL 5.61++/B.O.S 02.01) id AA01787; Fri, 1 Dec 95 15:33:06 -0500 Date: Fri, 1 Dec 95 15:33:06 -0500 Message-Id: <9512012033.AA01787@hfsi> From: "K Goertzel" Reply-To: "K Goertzel" To: mjr@iwi.com, firewalls@GreatCircle.COM Subject: Re: A1 Systems? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In message <199511302309.SAA04333@switchblade.iwi.com> writes: > >Now, to the Orange Book. The poster focused on features, but that is NOT > >the focus of the OB. The focus of the OB is ASSURANCE > > [...] > > >However, I will be happy to discuss any supposed "irrelevance" of OB or > ITSEC > >requirements to the commercial world. > > There's no need to -- you already explained (more tersely than > I did) the problem with the orange book earlier on in your comments. > > It's not about features, it's about assurance. > Commercial computing is about features (represented as functionality) > Therefore orange book is irrelevant to commercial computing. Please explain to me why any intelligent, self-respecting person in the commercial world would take *only* the vendor's word for the fact that his allegedly secure system was truly secure, rather than just a lot of marketing hype? It may be that we need another kind of security criteria for the commercial world. But it also seems to me that a commercial firm that doesn't try to get some kind of formal, independent, and competent assessment of the vendor's security claims deserves whatever lemon of a used car he buys. And I think the Citibanks of the world are already finding this out the hard way. Karen Goertzel Manager, International Programmes and Special Projects Secure Systems and Services Operation Wang Federal, Inc. 7900 Westpark Drive - MS 700 McLean, Virginia 22102-4299 TEL: 703-827 3914 FAX: 703-827 3161 Internet: goertzek@wangfed.com +-----------------------------------------+ | Human history becomes more and more a | | race between education and catastrophe. | | - H.G. Wells | +-----------------------------------------+ From firewalls-owner Fri Dec 1 15:34:35 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA11411 for firewalls-outgoing; Fri, 1 Dec 1995 15:21:07 -0800 (PST) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id PAA11406 for ; Fri, 1 Dec 1995 15:21:03 -0800 (PST) Received: by mycroft.GreatCircle.COM (8.6.10/SMI-4.1/Brent-950602) id PAA19328; Fri, 1 Dec 1995 15:21:02 -0800 Received: from uuneo.neosoft.com(206.109.1.3) by mycroft via smap (V1.3mjr) id sma019326; Fri Dec 1 15:20:54 1995 Received: from ris1.UUCP (ficc@localhost) by uuneo.neosoft.com (8.7.2/8.7.1) with UUCP id RAA00993 for GreatCircle.COM!firewalls; Fri, 1 Dec 1995 17:03:18 -0600 (CST) Received: by ris1.nmti.com (smail2.5) id AA04037; 1 Dec 95 17:12:38 CST (Fri) Received: by sonic.nmti.com; id AA29911; Fri, 1 Dec 1995 16:42:32 -0600 From: peter@nmti.com (Peter da Silva) Message-Id: <9512012242.AA29911@sonic.nmti.com.nmti.com> Subject: Re: chroot/setuid vs type enforcement To: smith@sctc.com (Rick Smith) Date: Fri, 1 Dec 1995 16:42:32 -0600 (CST) Cc: firewalls@GreatCircle.COM, smith@sctc.com, jeromie@garrison.com In-Reply-To: <199512011707.LAA17573@shade.sctc.com> from "Rick Smith" at Dec 1, 95 11:07:18 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > I have a fundamental distrust of chroot() because it's a band-aid. It's not a band-aid. The problem with chroot() is that Berkeley networking deliberately bypasses the basic UNIX security model. To open a port, you should execute an "open" system call on a special file, just as you open any other resource in the system. There should be no magic name spaces in a UNIX system... everything should be accessed through the file system. Therefore you would be able to do: chown /dev/tcp/ports/25 mail And sendmail wouldn't need to run setuid root... And chroot() would work... The problem with security on UNIX is entirely caused by people adding kludges that go around UNIX security. > It > is not designed to control access to system resources in a general > manner Yes it is. That's exactly what it's supposed to do. The problem is that there are system resources added later that aren't accessed through this general interface. From firewalls-owner Fri Dec 1 15:52:08 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA09086 for firewalls-outgoing; Fri, 1 Dec 1995 14:22:38 -0800 (PST) Received: from erenj.com (ereapp.ERENJ.COM [159.70.31.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA09080 for ; Fri, 1 Dec 1995 14:22:31 -0800 (PST) Received: from eredns.erenj.com(159.70.1.252) by ereapp.erenj.com via smap (V1.3) id sma013964; Fri Dec 1 17:22:38 1995 Posted-Date: Fri, 1 Dec 1995 17:22:36 -0500 Date: Fri, 1 Dec 1995 17:22:35 -0500 (EST) From: "Bryan D. Boyle" Subject: Re: FREE Proxy Server? To: Ming Ching Tiew Cc: firewalls@GreatCircle.COM In-Reply-To: <9512010308.AA03799@sparrow.Malaysia.Sun.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk this is probably off-topic, but the cern proxy server, available at http://www.w3.org/ is a good one. socksified, too... Bryan D. Boyle | EMAIL: bdboyle@erenj.com 908-730-3338 | PAGE: bboyle@apt1.pagemart.com #include | http://www.access.digex.net/~bdboyle/index.html "It seems that 'national security' is the root password to the Constitution. As with any dishonest superuser, the best countermeasure is strong encryption." -Phil Karn On Fri, 1 Dec 1995, Ming Ching Tiew wrote: > > Anybody has an answer to this ? > > ----- Begin Included Message ----- > > Subject: FREE Proxy Server? > > Dear Consultants, > > Do U know of any FREE-ly available http proxy server, providing a similar function to > Netscape Proxy Server? > > Regards, > > > -Raymond Chan > [rchan@abs.com.my] > > > ----- End Included Message ----- > > From firewalls-owner Fri Dec 1 16:01:03 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA11398 for firewalls-outgoing; Fri, 1 Dec 1995 15:18:40 -0800 (PST) Received: from main.geminisecure.com (main.geminisecure.com [205.179.16.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id PAA11393 for ; Fri, 1 Dec 1995 15:18:33 -0800 (PST) Received: (from leonard@localhost) by main.geminisecure.com (8.6.9/8.6.9) id PAA06052; Fri, 1 Dec 1995 15:12:39 -0800 Date: Fri, 1 Dec 1995 15:12:39 -0800 (PST) From: Leonard Miyata To: smith@sctc.com cc: firewalls@GreatCircle.COM, smith@sctc.com Subject: Re: chroot/setuid vs type enforcement In-Reply-To: <199512011707.LAA17573@shade.sctc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Fri, 1 Dec 1995, Rick Smith wrote: > jeromie@garrison.com asks about Marcus' kernel hacks: > Another problem, which is held by most alternatives that Marcus > noted in recent posts, is that correct behavior is in the hands > of the applications software. If the applications software goofs, > the protections are GONE. The underlying OS, whether it's a homespun > Unix kernel or a TCSEC evaluated platform, can't step in and help. > The application was responsible for setting up permissions and > if it goofs there's no way to tell good accesses from bad ones. > > Rick. > smith@sctc.com secure computing corporation > I would have to differ on the above statement. For those who don't know about Multi-Levl operating systems, a application for a "TRUSTED OS" is divided up into different modules with different levels of Security and integrity. The most common security model used from inter-process communications is that a 'Higher' level subject can 'Read Up' and 'Write Down' to a lower level subject, but the opposite is (with special exceptions) not allowed. This is enforced by multi-level Kernal and the CPU protected mode ring structure. The only exception to this is with 'Trusted Subjects' which 1. Require special Kernal Calls. 2. Can only be installed and configured in a off-line process. 3. Should be minimal for Trust and Verification. Once the Trusted Subject has been designed, implemented, and verified, the bulk of the rest of the Application is less of a problem. Say a programmer wrote a module after a All Night Party Binge. (Software Engineers are human after all!). If a feature (dressed up Bug) of a module tries to cross security levels outside the Trusted Subject, the security Kernal would immediatly stop the attempt. The unfortunate side-effect of this is that programming for a Trusted Security Kernal requires a greater level a programming skill then a conventional Box. On the Trusted Electronic Document Vault I've been working on for the SBA, the Vault Guard would rather Squawk, Croak, and Die first then allow a application to violate the security policy. This has been a pain at times, but such is the costs of Trust and Security Leonard Miyata aka leonard@geminisecure.com GEMINI COMPUTERS INC. Web Page http://www.geminisecure.com From firewalls-owner Fri Dec 1 16:02:57 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA11639 for firewalls-outgoing; Fri, 1 Dec 1995 15:40:02 -0800 (PST) Received: from mail3.pilot.net ([205.139.40.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id PAA11631 for ; Fri, 1 Dec 1995 15:39:56 -0800 (PST) Received: from unknown-23-140.noname.com (unknown-23-140.pilot.net [204.48.23.140]) by mail3.pilot.net with SMTP id PAA17368 for ; Fri, 1 Dec 1995 15:38:52 -0800 (PST) Received: from calvin.capgroup.com (mail.capgroup.com) by unknown-23-140.noname.com (4.1 1/7/93 /SMI-4.1) id AA14975; Fri, 1 Dec 95 15:40:43 PST Received: from samadams.capgroup.com (samadams.capgroup.com [148.107.150.66]) by calvin.capgroup.com (8.6.12/8.6.12) with SMTP id PAA05961 for ; Fri, 1 Dec 1995 15:39:09 -0800 Message-Id: <199512012339.PAA05961@calvin.capgroup.com> Received: by samadams.capgroup.com (1.38.193.4/16.2) id AA01326; Fri, 1 Dec 1995 17:37:48 -0600 Date: Fri, 1 Dec 1995 17:37:48 -0600 From: Brad Hawryluk (BHH) Apparently-To: firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hi, What is a lsof/ofiles program, and where does one get these?? # Previous mail here.......... From: Darren Reed Date: Sat, 2 Dec 1995 02:38:07 +1100 (EDT) Subject: Re: port number to process id In some mail from Peter Maersk-Moller, sie said: > > > Hi Firewall list ! > > Is there a standard way/script/tool (must cover most un*ces) to find the > relation between IP port number in use and id of the process using the port ? Most lsof/ofiles type programs will do this. lsof, in particular... cheers, darren From firewalls-owner Fri Dec 1 16:08:28 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA08168 for firewalls-outgoing; Fri, 1 Dec 1995 13:52:17 -0800 (PST) Received: from uuneo.neosoft.com (uuneo.neosoft.com [206.109.1.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id NAA08162 for ; Fri, 1 Dec 1995 13:52:10 -0800 (PST) Received: from ris1.UUCP (ficc@localhost) by uuneo.neosoft.com (8.7.2/8.7.1) with UUCP id PAA18829 for GreatCircle.COM!firewalls; Fri, 1 Dec 1995 15:42:03 -0600 (CST) Received: by ris1.nmti.com (smail2.5) id AA18087; 1 Dec 95 10:10:17 CST (Fri) Received: by sonic.nmti.com; id AA04804; Fri, 1 Dec 1995 09:40:16 -0600 From: peter@nmti.com (Peter da Silva) Message-Id: <9512011540.AA04804@sonic.nmti.com.nmti.com> Subject: Re: A1 Systems? To: mjr@iwi.com Date: Fri, 1 Dec 1995 09:40:16 -0600 (CST) Cc: spencerj@dg-rtp.dg.com, firewalls@GreatCircle.COM In-Reply-To: <199511302309.SAA04333@switchblade.iwi.com> from "Marcus J. Ranum" at Nov 30, 95 06:09:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > It's not about features, it's about assurance. > Commercial computing is about features (represented as functionality) > Therefore orange book is irrelevant to commercial computing. I have to say Marcus makes a good case. If assurance meant anything in the commercial world MS-DOS would have been sidelined by 1984. (sigh) From firewalls-owner Fri Dec 1 16:12:55 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA08048 for firewalls-outgoing; Fri, 1 Dec 1995 13:49:38 -0800 (PST) Received: from london.micrognosis.com (midas.london.micrognosis.com [193.114.123.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA08043 for ; Fri, 1 Dec 1995 13:49:33 -0800 (PST) Received: by london.micrognosis.com (4.1/NAR-Gateway) id AA29087; Fri, 1 Dec 95 21:50:17 GMT Received: from zeus.london.micrognosis.com(192.83.165.17) by midas via smap (V1.0mjr) id sma029085; Fri Dec 1 21:50:07 1995 Received: by zeus.london.micrognosis.com (4.1/SMI-4.1) id AA27332; Fri, 1 Dec 95 21:50:05 GMT From: nreadwin@london.micrognosis.com (Neil Readwin) Message-Id: <9512012150.AA27332@zeus.london.micrognosis.com> Subject: Re: tn-gw crash To: meyerd@Mailer.Uni-Marburg.DE Date: Fri, 1 Dec 1995 21:50:04 +0000 (GMT) Cc: firewalls@greatcircle.com In-Reply-To: <199512011428.PAA13134@post.med.uni-marburg.de> from "D.A. Meyer" at Dec 1, 95 02:23:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > I need comments on a system crash caused by tn-gw 1) Problems with tn-gw should go to the fwtk-users list at tis.com 2) A kernel panic is a Sun problem and so you should ask Sun 3) Since it's the holiday season ... the footprint doesn't look quite right but this may be the following bug which is fixed by patch 100804 (rev 2 or later, I have rev 3). If an application does a getsockopt() on a SOCK_STREAM (TCP) socket after the other side of the connection has sent a TCP RESET for the stream, the kernel gets a Bus Trap in the tcp_ctloutput() or ip_ctloutput() routine. Neil. -- nreadwin@micrognosis.co.uk Phone: +1 908 855 1221 x519 Anything is a cause for sorrow that my mind or body has made From firewalls-owner Fri Dec 1 16:24:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA12451 for firewalls-outgoing; Fri, 1 Dec 1995 16:15:04 -0800 (PST) Received: from ion3.ionet.net (ion3.ionet.net [204.96.200.8]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id QAA12444 for ; Fri, 1 Dec 1995 16:14:49 -0800 (PST) Received: from tektr.ionet.net (osip12.ionet.net [204.96.200.62]) by ion3.ionet.net (8.6.12/8.6.12) with SMTP id SAA05711 for ; Fri, 1 Dec 1995 18:15:35 -0600 Date: Fri, 1 Dec 1995 18:15:35 -0600 Message-Id: <199512020015.SAA05711@ion3.ionet.net> X-Sender: tektr@ionet.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "firewalls@GreatCircle.COM" From: Tim Richardson Subject: Firewall Selections Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hello All I have been given the task at my organization to investigate the various Firewalls that are on the market. We are currently looking at Firewall-1 and SunScreen. Does anyone have any good input or suggestions about these products? If anyone is using Sunscreen, is it worth the money? Any and all suggestions regarding any product would be helpful as I am new to the game. Thanks From firewalls-owner Fri Dec 1 17:54:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id RAA15095 for firewalls-outgoing; Fri, 1 Dec 1995 17:44:43 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id RAA15090 for ; Fri, 1 Dec 1995 17:44:39 -0800 (PST) Date: Fri, 1 Dec 1995 20:45:24 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951201204524.2021d3c0@hobbes.orl.mmc.com> Subject: Field of dreams Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >What a great idea! >A real set of security definitions based on real-world scenarios! >This HAS to be a first... We tried (firewalls-standards). Few came & it went downhill from there. Warmly, Padgett From firewalls-owner Fri Dec 1 20:03:08 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id SAA16927 for firewalls-outgoing; Fri, 1 Dec 1995 18:31:11 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id SAA16906 for ; Fri, 1 Dec 1995 18:31:04 -0800 (PST) Date: Fri, 1 Dec 1995 21:31:54 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951201213154.2021d3c0@hobbes.orl.mmc.com> Subject: re: A1 systems Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > There are still orange book systems out there, and there >are still people working on them, but that's really part of the >government's typical inability to terminate an unsuccessful >program. It is not so much the gov's inability to terminate as its inability to replace it with something better. I spent several years as a Mil-Std-1750A egg-spurt mostly explaining why you really did not want to use Mil-Std-1750A. Problem was that Mil-Std-1750A defined a 16 bit *embedded airborne* "Instruction Set Architecture". Not bad if you consider it was designed by committee but its real function was to be able to handle integer and floating point operations. To do this it was designed to manipulate 16 bit words very well. What it could not do was manipulate bytes (we used to describe Mil-Std-1750A systems as "a coprocessor in search of a processor"). ASCII is in bytes. Character based displays (this was 1979-1985 era) rely on ASCII. You get the picture. Now there was another Mil-Std, 1862 AFAIR for a 32 bit ground based computer that was designed by another committee to handle such things. For some unknown reason, Mil-Std-1862 was cancelled. This left Mil-Std- 1750A. For Everything. I once saved nearly $10 million dollars on a program by replacing the Mil-Std-1750A "system" on a ground program with microVAXes. The fact that there was NWIH to meet the schedule as promised also crossed my mind. However it took some fast talking with the Air Force (AFR 33 - again AFAIR, no promises - said in no uncertain terms 1750 - the fast talking involved a paragraph that said "or 32 bit computer" creative interpretation of a single comma was required 8*). Even there I cannot take all the glory, my original proposal was to use VAX 11/725s (don't ask). Thank goodness the microVAX came out before we had to demo the system... The whole Rainbow Series has the same problem. If you remember back in 1993 when the first Clipper briefing was held at NIST, on the same day a similar briefing was held for the replacement for the Orange Book, called the Federal Criteria (draft), something that had been around for several years already, ever since People Who Know realized that there were some limitations to the Rainbow series. Unfortunately, like Mil-Std-1862, the Federal Criteria was cancelled and was supposed to be replaced with some other Criteria, which was cancelled and replaced by something else, and eventually the whole thing became the Common Criteria, an International effort (when you see B2/E4, the E4 is CC rating) which some have maybe adopted - I'm not really sure since my main focus lately is US/commercial (the '90s, the decade of exhaustion). So what we have as a standard is the Rainbow Series. Everybody agrees it is limited and does not really fit anymore - at least not as well as it did in 1984 when a network was two VAXes connected by dedicated fiber and terminals were RS-232 links to mainframes. But when you see the term "Information Systems Security Officer" (often just security officer), for an explination of just what that means and what reponsibilities that entails, you have to turn to the Rainbow Series (the turquoise book ? - my set is in the office). No wonder they insist on Orange or Red Book evaluation, their whole job is defined in those terms and obsolete or not, it is all they have. Realize this is not entirely firewalls oriented but in order to understand why people do some of the apparently dumb things they do, you have to understand why they do them. To know where we are going, you have to know where we are coming from, otherwise it all appears to be chaos. (actually it is Benoit's baby and we are all fractals...sorry, I keep coming unstuck in time...anyone have some Tang ?). Still, Orange book ratings do have meaning and value to firewalls. IMNSHO a firewall *must* meet most B2 criteria and need not exceed B3. Is not all you need but is an excellent place to start (note: numbers ascend for increasing strength, letters decend. Now doesn't that make sense ? If it does, let's try the US Highway numbering system and its correlation to Interstates 8*). Warmly, Padgett ps now Rexx makes sense. From firewalls-owner Fri Dec 1 20:09:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id SAA17732 for firewalls-outgoing; Fri, 1 Dec 1995 18:40:51 -0800 (PST) Received: from northshore.ecosoft.com (northshore.ecosoft.com [192.233.85.129]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id UAA11229 for ; Tue, 28 Nov 1995 20:58:50 -0800 (PST) Received: from [198.115.179.204] (slip-3-4.shore.net) by northshore.ecosoft.com with SMTP id AA15321 (5.67a/IDA-1.5 for ); Tue, 28 Nov 1995 23:58:52 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Nov 1995 01:05:40 -0500 To: Firewalls@greatcircle.com From: vin@shore.net (Vin McLellan) Subject: SDI's Time-Synched SecurIDs (3 of 3) Cc: padgett@hobbes.orl.mcc.com, WHMurray@aol.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk (Fair warning! If you've had your fill of SecurID and discussion of time-synchronous OTPs and their future prospects, jump to the next post and fare thee well.) Our highly-esteemed Padgett Peterson has declared his certainty that evolving and future applications will topple the bandwagon for the user-friendly SecurID, a popular OTP token which displays a PRN "card-code" which changes every 30 or 60 seconds. Padgett dug a hole at the crossroads; fashioned a strawman for the coffin, and buried it deep -- sprinkling rare herbs and muttering (at least to my ears, warmly;-) a benediction and something about a desperate need for a sharp oak stake. Because of his "reservations" about the burden managing a time-synchronous application places upon his host computer -- the vaunted "complexity" of TS -- Padgett is eager to retreat to the logical simplicity of a challenge/response (C/R) exchange. And he thinks that is possible because he expects the human element -- the typical user's frustration with the multi-step C/R exchange -- to be of vastly diminished importance. Said Padgett: >In the past, this "fuzzy authentication" has been acceptable since the risk is >small and the users like not having to enter anything into the card. >However the great leveler - soft tokens where the user just enters a PIN >an all else is automatic - is considerably "fuzzier" where clocks are >concerned, and the first thing that goes when the CMOS battery decays is >the precision of the clock. What was the phrase Mr. Murray used? Yup, Padgett is incorrigible. It would doubtless take Padgett Peterson 20 minutes to do a rough design for a TS system where any Time signal factored into an all-software pseudo-token (on say, a networked PC) comes not from the PC's untrustworthy clock, but from the remote ACM server. (Actually, SDI clients -- part of the client/server architecture that already serves a third of SDI's installed base -- already draw a Time signal from the ACE/Server -- as part of the mechanics for mutually authenticating the server and the client, every time they handle a SecurID authentication call.) SDI is telling their customers that they will offer an ACE/Server-compatable software-based OTP authentication package next year. (I don't know which scheme they will use. The SDI labs had developed and tested four different designs extensively. The SDI software OTP will probably not be called SecurIDs, and they will surely use a different algorithm: the one-way function that, in the SecurID, takes Time and a token-specific secret key and puts both through a keyed hash algorithm to generate an irreversible and unpredictable PRN card-code. Personally, I believe "soft tokes" are great for user ID authentication in many environments. Cheap and a vast improvement over reusable passwords. Many of them, commercial and freeware, will doubtless be C/R devices. I hold no brief against C/R, a mature and secure tech, other than to point out the obvious: working with a HHA, a physical C/R token, is a major (and comparative) hassle. Only when you automate the C/R exchange with "pseudo-token" software or PCMCIA smart cards with plug-in connections, will that hassle be ameliorated. Thus, Padgett's case. (Of course, OTP security tokens -- physical hardware; software; or "hot- wired" -- are only part of a system sell. The database and administrative software that support user authentication will be an increasingly important part of future OTP sales, as the whole-Enterprise market looms. I won't get into that, only because Padgett left enough on my plate, this is already too long, and I've got points yet to score;-) Software pseudo-tokens ('soft tokes") are not, however, nor will they ever be, equivalent in security or the confidence they inspire to a _physical_ security token. (By classical definition: "something held;" assigned to an individual; and difficult to counterfeit.) Software can always be copied, read. The security of such a device is wholly dependent on the physical security for the cpu which holds it. And any pseudo-token software in the field (often, probably, PC-hosted) will have to "know" -- hold somewhere in memory -- both the user's PIN and the "token's" secret key . As I've said before (Padgett's antipathy to TS and his hope that "soft tokes"might reverse the market tide for C/R is not new,) I will always assume a Padgett Peterson or his peer could pry those secrets out of a pseudo-token software package overnight. For all of us obsessed with data security, data integrity, and privacy -- on the Net and off -- encryption is the Grail. With all his worries bout the burden TS complexity puts on his CPUs, Padgett is eager to discard the ease-of-use of TS because he looks beyond OTPs, beyond user ID authentication -- to a hopeful Golden Age where OTP-like tokens can be widely used for crypto key "distribution." I happen to agree that hardware tokens look very attractive as crypto key holders/generators, but IMHO, Padgett distorts the relative potential of the two types of tokens here again (and worries bout complexity in all the wrong places;-). >Further, use of tokens for creation of secure channels requires exact >precision - use the wrong key and you won't communicate (not saying you >cannot create a secure channel with TS - I discussed a means with the >people at Allwife Center over a year ago - just is more difficult). I'm not part of SDI's internal planning, but it seems obvious to me that, if an ACE/Server can recognize a valid card-code in a SecurID authentication call, it can recognize and decrypt anything encrypted using that card-code as a crypto key. (Even dealing with worse-case drift doesn't seem difficult -- use a digest, and validate the key before tackling decryption. But then, I suppose I've already proven how little I appreciate the burden of complexity on a well-bred CPU.) Padgett, in another post, suggested how a C/R token would used to generate a crypto-key in response to a random challenge sent up from a host or server. The "response" would be calculated by feeding the challenge to a token (or a software pseudo-token) but it would never transmitted over the net. Instead it would be used as the key to established a secure channel, using encryption. "By the ability to communicate both ends would be authenticated to each other." Others might feel, as I do, that two-factor authentication is still important with a dispersed link-encryption scheme. But the interesting question here is how the crypto-key is handled. A community of crypto-loaded PC, with keys installed, is an abomination. So we are left with the key held in a OTP-like token: a SecurID or one of the C/R tokens. Be that the case, I'll bet Padgett a fine dinner that, in actual practice, the use of a SecurID as a crypto key "distributor" will have almost the same advantage in ease-of-use over any C/R token as it has today in ID authentication. Keystroke for keystroke. At least until PCMCIA cards rule the world and every keyboard has a port for them, SDI's time-synch tokens will provide greater security (hex alphanumeric card-codes, already available on request) for crypto key distribution -- actually "key generation" in the SecurID PRNs -- with significantly less hassle. No waiting for a challenge after logon; no tapping the PIN and the challenge into a credit-card key pad; no typing the token's response to the crypto engine at the terminal. My presumption is, a SecurID user will type in a name or user ID, a memorized PIN, and his SecurID card-code -- period! -- to get a secure crypto link _and_ two-factor ID authentication. (SDI's Ken Weiss has some patents on TS in crypto which seem to promise just this.) It's doubtless clear to all that -- whatever the complexity of a TS linkage -- once one SecurID card-code is used to provide authentication, 30 or 60 seconds later, the next one (known at both the token and the host, but never transmitted) can be used as a secure crypto key. But there are shortcuts possible.... A crypto engine in an ACE client could use a single card-code as the key to encrypt a digest packet or even brief message (say the word "security") and resulting ciphertext could be sent -- in a packet encrypted yet again, after the client and server mutually authenticate -- to the distant ACE/Server. The ACE/Server -- knowing the word "security," and able to quickly confirm that this ciphertext was sent with a card-code from a specific SecurID assigned to a specific user -- will simultaneous authenticate the sending user (using two factors!) and establish a secure crypto link. As needed, another secure link to another user could be established for person-to-person secure comm. Crypto: painless and transparent. And in the world beyond -- when we're all carrying PCMCIA cards and every keyboard has a slot -- even today's SecurID, plugged into a socket, could provide a new key of virtually *any* length _every 15 seconds_ for secure communications. Padgett argues that TS tech is a dead duck. I obviously disagree (which will come as no surprise to Listocrats familiar with my POV and long-time consulting ties with SDI.) I think the TS technology has yet to come into its own, despite it current prominence in the OTP token market. Apologies to anyone offended or put to sleep by the weight on the bandwidth. Some detail about the SecurID and TS mechanics seemed necessary, since some very bright guys had the basics wrong. Please write SDI directly (sdi@shore.net or http://www.securid.com) for product information. I speak just for myself and the Privacy Guild. Suerte, _Vin Vin McLellan +The Privacy Guild+ 53 Nichols St., Chelsea, Ma., USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*> From firewalls-owner Fri Dec 1 20:31:02 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id SAA17948 for firewalls-outgoing; Fri, 1 Dec 1995 18:43:17 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA02678 for ; Wed, 29 Nov 1995 10:41:42 -0800 (PST) Received: from Corp.Sun.COM by mercury.Sun.COM (Sun.COM) id KAA04331; Wed, 29 Nov 1995 10:42:27 -0800 Received: from themall.Corp.Sun.COM by Corp.Sun.COM (5.x/SMI-5.3) id AA29003; Wed, 29 Nov 1995 10:42:25 -0800 Received: by themall.Corp.Sun.COM (5.x/SMI-SVR4) id AA09455; Wed, 29 Nov 1995 10:46:41 -0800 Date: Wed, 29 Nov 1995 10:46:41 -0800 From: Judy.Reynolds@Corp.Sun.COM (Temp Contractor) Message-Id: <9511291846.AA09455@themall.Corp.Sun.COM> To: firewalls@greatcircle.com Subject: help Cc: Judy.Reynolds@Corp.Sun.COM X-Sun-Charset: US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hello, I am hoping that someone may be able to give me a lead. I need assistance from someone with expertise in internet security, network management and consulting. If you can help or know someone I should talk to, please respond. Thanks. Judy.Reynolds@Corp.Sun.Com From firewalls-owner Fri Dec 1 21:24:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id TAA19329 for firewalls-outgoing; Fri, 1 Dec 1995 19:11:58 -0800 (PST) Received: from gateway.kellogg.com (gateway.kellogg.com [198.108.149.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id TAA19324 for ; Fri, 1 Dec 1995 19:11:46 -0800 (PST) Received: from cornelius.scp.com (kellogg.com) by gateway.kellogg.com with SMTP id AA07023 (InterLock SMTP Gateway 3.0 for ); Fri, 1 Dec 1995 22:11:18 -0500 Received: from ccMail by cornelius.scp.com (IMA Internet Exchange v1.04) id 0bf2c6c0; Fri, 1 Dec 95 11:25:16 -0500 Mime-Version: 1.0 Date: Fri, 1 Dec 1995 11:13:55 -0500 Message-Id: <0bf2c6c0@cornelius.scp.com> From: Alex.Eveleigh@kellogg.com (Alex Eveleigh) Subject: Security of Leased Lines To: firewalls@greatcircle.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I am interested in getting some feedback on how difficult it would be for someone to tap a leased line for a network connection and what possible defenses there are to reduce the risk of information transported on leased lines being monitored. Thanks in advance, Alex From firewalls-owner Fri Dec 1 21:40:39 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA22369 for firewalls-outgoing; Fri, 1 Dec 1995 20:08:48 -0800 (PST) Received: from switchblade.iwi.com (switchblade.iwi.com [137.39.156.214]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id UAA22354 for ; Fri, 1 Dec 1995 20:08:41 -0800 (PST) Received: (from mjr@localhost) by switchblade.iwi.com (8.6.9/8.6.9) id XAA14695 for firewalls@greatcircle.com; Fri, 1 Dec 1995 23:09:57 -0500 From: "Marcus J. Ranum" Message-Id: <199512020409.XAA14695@switchblade.iwi.com> Subject: selection criteria? To: firewalls@greatcircle.com Date: Fri, 1 Dec 1995 23:09:57 -0500 (EST) Reply-To: mjr@iwi.com Organization: Information Warehouse! Inc, Baltimore, MD URL: mjr's web page Phone: 410-889-8569 Coredump: Infocalypse Now!!! X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Paul Merenbloom drops a small bomb: >What would you consider the top 5-10 issues? How does price >sensitivity (or lack thereof) affect your rankings / issues? On what >basis would (or have) you made your decisions (or guided others)? I played a naughty little game at a conference recently where I polled the room by show-of-hands as to what were the important things they looked for in firewalls. Features, price, and vendor reputation were pretty much the top categories. I'd cheated and left "security" off my list and I thought I was going to get away with it until someone flagged me when I asked "are there any criteria I forgot to put on the list...?" That put features, price, vendor reputation, and security all at the top. Then there's everything else. Moubray, Steve writes: >Criteria # 1 is your needs. >Criteria # 2 is support. >Criteria # 3 reputation and staying power. 'nuff said. :) mjr. From firewalls-owner Fri Dec 1 21:54:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA28569 for firewalls-outgoing; Fri, 1 Dec 1995 21:40:19 -0800 (PST) Received: from smtp2.interramp.com (smtp2.interramp.com [38.8.200.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id VAA28558 for ; Fri, 1 Dec 1995 21:40:15 -0800 (PST) Received: from [38.12.4.39] by smtp2.interramp.com (8.6.12/SMI-4.1.3-PSI-irsmtp) id AAA28747; Sat, 2 Dec 1995 00:38:31 -0500 Date: Sat, 2 Dec 1995 00:38:31 -0500 X-Sender: cd000565@pop3.interramp.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "K Goertzel" From: Pelican@interramp.com (Bob McKisson) Subject: Re: A1 Systems? Cc: Firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >In message <199512011931.NAA23745@shade.sctc.com> Rick Smith writes: > >> This argument doesn't work for firewalls. You end up trusting the >> vendor's word anyway. Karen sezz... >Not strictly true in the military and other parts of the goverment, where they >have something called the system accreditor whose job it is to at least >validate >the vendor's claims. That certain civilian agencies and less enlightened >members of private industry are either too naive, too cheap, or too lazy to do >the same means they only get what they deserve when the firewall fails to >protect them as advertised. You mean like the folks who failed to validate the performance of the management teams at Wang and Honeywell Federal Systems before they bought their stock?...and the government agencies that bought train loads of "validated and accredited" TEMPEST systems from those companies? :) Oh yes indeed. Let's talk about the perfect world of trusted systems and vendors claims. :) rmck ________________________ Bob McKisson President Cypress Systems Corporation 3702 Pender Dr. Fairfax, VA 22030 (703) 273-2150 Voice (703) 273-2151 FAX (703) 691-2434 STU-III From firewalls-owner Fri Dec 1 22:24:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id TAA20207 for firewalls-outgoing; Fri, 1 Dec 1995 19:32:25 -0800 (PST) Received: from firewall.mc.com (firewall.mc.com [192.148.197.15]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id TAA20193 for ; Fri, 1 Dec 1995 19:32:17 -0800 (PST) Received: by firewall.mc.com id AA15075 (5.65c/IDA-1.4.4 for ); Fri, 1 Dec 1995 22:33:05 -0500 Received: from jericho.mc.com(192.233.16.4) by firewall via smap (V1.3) id sma015071; Fri Dec 1 22:32:39 1995 Received: from beachball.mc.com (beachball [192.233.16.7]) by jericho (8.6.11/8.6.11) with SMTP id WAA22491 for ; Fri, 1 Dec 1995 22:32:37 -0500 Received: by beachball.mc.com (5.x/SMI-SVR4) id AA02418; Fri, 1 Dec 1995 22:31:23 -0500 Date: Fri, 1 Dec 1995 22:31:23 -0500 From: blu@mc.com (Brian Utterback) Message-Id: <9512020331.AA02418@beachball.mc.com> To: firewalls@GreatCircle.COM Subject: Need firewall to support enterprose private addresses X-Sun-Charset: US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk My company has two problems. One, we need a firewall system. We have been using the FWTK plus packet filtering on the router provided by our ISP, but we are about to change ISP's and we have never been comfortable with having someone else responsible for our security. Consequently, we are in the market for a full commercial firewall system. The second problem is that we are running out of IP addresses in our internal networks. We have several class C networks assigned to us, but our network partitions into two logical networks. Each of these are already at about 250 or so hosts, with more on the way. So, I see two possible solutions. First possibility, combine our Class C addresses. Our addresses are 4 consecutive networks, with the third octets being 16, 17, 18 and 19. We are maxed out on 16 and 17, with 18 unused and 19 nearly so and able to be folded into one of the other nets. My thought is to specify a subnet mask of 255.255.254.0 and logically combine the four networks of 255 addresses each into 2 networks of 510 addresses each. The only problem I have is I don't know if that is even legal, or if so, then if it is supported by the vendors of our systems. We are mixed Sun, SGI, Mac, PC. The second possibility is ( I bet you can guess this one) is to get a address translating firewall and use the enterprise private Class B network. There are two ways that this can work as near as I can tell. One is like the Private Internet Exchange from Network Translation ( now Cisco ) which uses dynamic packet filtering to transparently map the addresses used. The other is via a set of application gateways, so that all connections appear to be from the Firewall system. The problem I have is that I do not know which firewalls can do which of these types of translations. Gauntlet used to be able to do this via the application gateway route, but with the semi-transparent proxies they have developed, I do not know if this is still the case. So how about it you firewall vendors and evaluators, which firewall systems can help me out? Which firealls support use of enterprise private addresses? 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 Fri Dec 1 22:54:13 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA27485 for firewalls-outgoing; Fri, 1 Dec 1995 21:24:51 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id VAA27479 for ; Fri, 1 Dec 1995 21:24:41 -0800 (PST) Message-Id: <199512020524.VAA27479@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA066721928; Sat, 2 Dec 1995 16:25:28 +1100 From: Darren Reed Subject: A1 systems as firewalls ? To: Firewalls@GreatCircle.COM (Firewalls Mailing List) Date: Sat, 2 Dec 1995 16:25:27 +1100 (EDT) In-Reply-To: <9512012044.AA01855@hfsi> from "K Goertzel" at Dec 1, 95 03:44:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In some mail from K Goertzel, sie said: > > In message <199512011931.NAA23745@shade.sctc.com> Rick Smith writes: > > > This argument doesn't work for firewalls. You end up trusting the > > vendor's word anyway. > > Not strictly true in the military and other parts of the goverment, > where they > have something called the system accreditor whose job it is to at least > validate > the vendor's claims. That certain civilian agencies and less enlightened > members of private industry are either too naive, too cheap, or too lazy > to do > the same means they only get what they deserve when the firewall fails to > protect them as advertised. I've picked this e-mail for no particular reason, but I think the point of A1 systems and firewalls is being lost and this debate, whilst interesting is becoming more peripheral to firewalls as time progresses. What's gained from having a certified A1/B3/Z99 system is assurance that if someone actually gets into the system, you stand a better chance of them not being able to cause disruption of the actual firewall service, or perhaps, even get into the internal networks. So even if your proxy or sendmail daemon has a buffer overrun bug lurking in it that you're unaware of, if it gets exploited then it poses no threat to the firewall, as a whole (except for maybe that service itself). Have I got that right ? Further to this, A1 systems are meaningless for firewalls that exist entirely of packet filtering related technology (ie Firewall-1, using routers, etc), unless the system performing the firewall functions happens to also run sendmail/news, etc. That is unless you do packet filtering outside of the kernel (a la screend). I wonder, are Cisco ever going to have their IOS evaluated under the Orange (or some other colour) book ? If we look at an extreme case, where the firewall only does packet filtering (lets assume that it's IP code is 100% rock solid - O:-) and provides no network access to itself, then what does it being any Orange book rating buy me ? It runs no process which could be exploited for bugs nor provide any interface for an attacker to grab onto. Possibly SunScreen (and other NATs) fit into this category. Further more, just because a system is B3 or A1, it doesn't mean that it is protected from user (operator) error or flaws in the firewall design. One more thing I'd like to bitch about...(Marcus pointed this out to me recently and now that I look, it's rather sickening...) This is a firewalls mailling list. It isn't a forum for telling wonderful stories (no matter how good or bad) about Military standards or anything else. These usually have little bearing on firewalls in use today. If you would like to tell stories and show how wonderful your past is (I _do_ hope you put these on your resumes/c.v's!) maybe you should make another list or form comp.security.stories. I really don't care about your personal history and it's relevance to firewalls is obscure, at best, unless you need to prove your expertise and how qualified you are in commenting on this subject. To this I say "more action and less talk". Network security has some way to go yet, find something worthwhile to do with your time and spend less telling stories. Please keep mail to the list about firewalls (and their related technFrom firewalls-owner Sat Dec 2 07:24:14 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA16390 for firewalls-outgoing; Sat, 2 Dec 1995 07:17:58 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA16385 for ; Sat, 2 Dec 1995 07:17:54 -0800 (PST) Date: Sat, 2 Dec 1995 10:18:46 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951202101846.20219446@hobbes.orl.mmc.com> Subject: Security of leased lines Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Alex rites: > I am interested in getting some feedback on how difficult it would be > for someone to tap a leased line for a network connection Pay a skilled person enough to take a job as a janitor. > and what > possible defenses there are to reduce the risk of information > transported on leased lines being monitored. Encrypt. Everything. Warmly, Padgett From firewalls-owner Sat Dec 2 08:01:53 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA16604 for firewalls-outgoing; Sat, 2 Dec 1995 07:35:50 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA16599 for ; Sat, 2 Dec 1995 07:35:47 -0800 (PST) Date: Sat, 2 Dec 1995 10:36:38 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951202103639.20219446@hobbes.orl.mmc.com> Subject: of mice and Marcus Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Wrong simile. Marcus does not have a security problem with cats, his problem is with flowerpots. Cats are a different problem (had to remove the headboard/launching pad from the bed as a result of the 4 am stanpedes.) Warmly, Padgett From firewalls-owner Sat Dec 2 08:07:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA16362 for firewalls-outgoing; Sat, 2 Dec 1995 07:08:50 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA16357 for ; Sat, 2 Dec 1995 07:08:46 -0800 (PST) Date: Sat, 2 Dec 1995 10:09:37 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951202100937.20219446@hobbes.orl.mmc.com> Subject: re: SDI etc. (3of3) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Vin has an absolutely fabulous way with the English language, his postings are a joy to read. I just happen to disagree. Just one point: > It would doubtless take Padgett Peterson 20 minutes to do a rough >design for a TS system where any Time signal factored into an all-software >pseudo-token (on say, a networked PC) comes not from the PC's untrustworthy >clock, but from the remote ACM server. (Actually, SDI clients -- part of >the client/server architecture that already serves a third of SDI's >installed base -- already draw a Time signal from the ACE/Server Am a bit confused here. How is this different from challenge/response except that instead of an unpredictable challenge, you are exchanging a very predictable (and spoofable) time hack that is used to develop the response ? I mean "let's synchronize our watches" went out as soon as earpiece communicators (like the SS wears) became available. Warmly, Padgett ps does "telegraphic style" mean "short" ? (Years ago I took a course on the EPTAK programmable controller - was about 1975 and the thing was 8080 based - coldest week of my life was spent in Davenport Iowa then, day I left, it got up to zero. Farenheight. Three weeks later I was using the $50k controller to "fly" an afterburning military gas turbine engine in the high altitude chanber at Tullahoma instead of the $250k relay panel used before. Was actually the first such digital engine test since the Pratt DEEC did not reach the test stand until later. Of course the test was classified so got no publicity as such. Funny thing was it made a standard '60s joke about "we did it first" true 8*). At any rate, I was a good little student up until the final exam (you can stop if you have heard this before). The test was to make a light bulb blink. I'm thinking about pulse-width-modulated afterburner fuel flow at 50,000 feet. The instructor says "passing is twelve instructions, our engineers have done it in nine". Using maxterm/minterm logic I do it in seven. Light blinks. Instructor complains that I never initialized the circuit. I was a bit younger then and not so easy to get along with. "You just said to make the bl**dy thing blink, not where to start." pps anyone who thinks "rocket science" is easier than the Orange Book has never studied transonic gas flow charactoristics in a convergent-divergent 2-D vectoring nozzle or choked-flow reversion waves in ducts of high- bypass turbofans. Does come in handy for "rule bending" in race car fuel injections. Used to get over 900 cfm out of a 600 cfm Rochester FI. Cram enough air in and a small block Chevvy will wind to the moooon 8*). From firewalls-owner Sat Dec 2 08:35:18 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA16442 for firewalls-outgoing; Sat, 2 Dec 1995 07:28:09 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA16437 for ; Sat, 2 Dec 1995 07:28:05 -0800 (PST) Date: Sat, 2 Dec 1995 10:28:57 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951202102857.20219446@hobbes.orl.mmc.com> Subject: re: A1 systems Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Sten rites: > Given the success of Microsoft with Windows, you must be right. >In commercial computing, it doesn't matter if the features work >properly, just that there is an assertion that the features are there, >and will work Real Soon Now. Then again if all of the nodes were secure, we would not have a problem. It is the fact that the nodes are not secure and in fact it is impossible to secure them (partly due to M$, partly due to lack of resources) that we had to move the security to a different point in the organization, a manageable point, hence Firewalls. Neither good nor bad, just is. Warmly, Padgett From firewalls-owner Sat Dec 2 08:39:06 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA16219 for firewalls-outgoing; Sat, 2 Dec 1995 06:58:58 -0800 (PST) Received: from switchblade.iwi.com (switchblade.iwi.com [137.39.156.214]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA16208 for ; Sat, 2 Dec 1995 06:58:52 -0800 (PST) Received: (from mjr@localhost) by switchblade.iwi.com (8.6.9/8.6.9) id JAA03362; Sat, 2 Dec 1995 09:57:22 -0500 From: "Marcus J. Ranum" Message-Id: <199512021457.JAA03362@switchblade.iwi.com> Subject: Re: A1 Systems? To: goertzek@gateway.wangfed.com Date: Sat, 2 Dec 1995 09:57:21 -0500 (EST) Cc: firewalls@greatcircle.com Reply-To: mjr@iwi.com Organization: Information Warehouse! Inc, Baltimore, MD URL: mjr's web page Phone: 410-889-8569 Coredump: Infocalypse Now!!! X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk [Normally I wouldn't reply to something like this to the whole list, since it's a bit ad hominem even for the firewalls mailing list, and it's really best to say these things offline where there's less room for mutual embarrassment. However, since Karen seems to have some misonceptions about me that she's willing to publicly air, I'd like a chance to correct them.] K Goertzel writes: >I just warn those on this group who hadn't already figured it out >for themselves that Mr. Ranum's extremely negative opinions vis >the NSA evaluation process are highly biassed and should in no way >be taken as fact, or even as representative of a rational opinion >on the subject. Negative opinions should never be "taken as fact." They are, indeed, opinions. They also are, indeed, extremely negative, with respect to many aspects of the ITSEC. People who have had the intestinal fortitude to follow some of my other opinions will recall that I have often pointed out that basically, ITSEC is not a bad idea - it's just a flawed, useless implementation. Anyhow - be that as it may - I don't think the readership of this mailing list is so dumb that you need to come in and play umpire, effectively saying, "Marcus is a whacko and is not rational on this topic." If the readership of this list decides that, they are welcome to -- but I doubt they need your help. I'm sure that everyone appreciates your selfless(*) efforts, though. >While TCSEC and ITSEC evaluations have their >problems, Mr. Ranum, an ex-TIS employee who clearly feels he was >somehow "burned" by the TCSEC evaluation process at "high assurance" >levels, clearly has an axe to grind that prevents him from providing >anything like a helpful, well-reasoned opinion of these matters. Actually, I can see how someone who knows nothing about me or who has never met me might jump to such a completely inaccurate conclusion. What's impressive is that you had the courage to post it to the entire list, and the lack of wisdom to ask me offline if it was the case. :) That being said, when I worked at TIS I had nothing whatever to do with the TCSEC systems or process. In fact, never, once, in my career have I had anything more than a peripheral involvement with TCSEC or its systems. It has never cost me any time, money, or pain. My work at TIS was strictly butthonholed into firewalls and the whitehouse.gov work, and my only association with TCSEC systems was from watching the smoke clouds and battle-damage at a distance. It *DID* give me a good opportunity to learn more about them, and to decide that practically it is an unworkable approach. That you feel I clearly have an axe to grind is somewhat correct: I think that TCSEC is a false god that has set computer security back 10 years, through its mindless adherence to rote checklists and entrenched procedures, rather than a creative and dynamic approach. I am an engineer, not a politician, or marketer, and I despise seeing "solutions" that do not work foisted off on the taxpayers (some of whom read this list!) as god's own solution to every problem on earth. But, whether or not I think TCSEC is stupid, or whether or not you feel I am irrational on the topic, I'd prefer you to address my arguments on their merits, rather than by trying to dismiss me to the readership at large as a whacko. They already *KNOW* I am a whacko, Karen. :) But that doesn't mean I am *WRONG*. Rick, from SCTC, has made lots of postings to this forum, which represent the good parts of the TCSEC process. Yes - people have learned a lot of useful things from it. Indeed, it has produced security expertise such as Rick represents. That's great and that's valuable. What sends me off is when vendors, who have invested huge amounts of their money (and huge amounts of the taxpayer's money!) to produce systems that are unworkable, unweildy, and obsolete, try to push them off as something that is cutting edge and wonderful -- and it works. The vendors are ruthlessly exploiting the customers' ignorance about security. It is short-sighted and fundamentally wrong and if you detect that I am annoyed by that fact, you are 100% correct. Look at the recent nonsense from Microsoft, where they lobbied through a certification of Windows NT at C2(yawn!) so they could tout it as a secure system and score marketing points. Doesn't that bother you just a little bit??? Many of the people who read this list understand the bogosity of Microsoft's move - I'd be surprised if a few of the vendors who have slaved in the TCSEC world aren't a bit annoyed by it. What has happened to TCSEC is that it's no longer about security, it's about politics, vendor lock-out, rigging procurements by eliminating more cost-effective systems, and turf warfare within the DOD community. *THAT* is the part of TCSEC that I have seen. So, yes, I tend to throw the baby out with the bathwater. Sometimes it's worth it. >As for his opinions on MULTICS, I happen to know many dozens of >former Multicians, all of whom would loudly disagree with his "one >man's opinion". Yep, that's fine. There are always a few. I know folks who swear TOPS-10 is the best thing (still!) since sliced bread. That's fine. But you can't tell me it's state of the art. :) I kind of wish I hadn't thrown away my DOCKMASTER manuals. The command environment of MULTICS is useful for would-be UNIX gurus to study as compuarcheology. It shows you clearly what K&T&R were reacting *TO* when they designed UNIX. And why. :) >I do not wish to start a flame war with Mr. Ranum, but I have been >following his opinions on high-assurance evaluations for several >months now, and have yet to find anything like a calm, well-reasoned >opinion in any of his diatribes on the subject. Obviously! :) Launching ad hominem attacks is the classic way of not starting a flame war! :) Rick Smith has been doing an excellent job of pointing out the good parts of the orange book approach, and has been rationally contrasting the perspective I am presenting (the "just hack it!" engineer) against the formal methodologist. That's a worthwhile discussion. If you think my diatribes are irrational, that's fine, but simply trying to dismiss me is not a very strong argument against my position. mjr. ---- * >Karen Goertzel Manager, International Programmes and Special Projects >Secure Systems and Services Operation Wang Federal, Inc. 7900 >Westpark Drive - MS 700 McLean, Virginia 22102-4299 From firewalls-owner Sat Dec 2 08:54:14 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA17082 for firewalls-outgoing; Sat, 2 Dec 1995 07:59:18 -0800 (PST) Received: from pimaia2w.prodigy.com (pimaia2w.prodigy.com [192.207.105.46]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA17070 for ; Sat, 2 Dec 1995 07:59:13 -0800 (PST) Received: from mail.prodigy.com (mail.prodigy.com [199.4.137.13]) by pimaia2w.prodigy.com (8.6.10/8.6.9) with SMTP id KAA57878 for ; Sat, 2 Dec 1995 10:59:55 -0500 Date: Sat, 02 Dec 1995 11:00:07 EST From: HFDK41A@prodigy.com (MR. JOHN K MOLNAR) X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-334.50] Message-Id: <013.05921740.HFDK41A@prodigy.com> To: Firewalls@GreatCircle.com Subject: Desperate for people!! Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hi- I know this may be a bit off topic, but I've been a participant and a lurker for a couple of months and now I really need some help. I'm looking for two people who know about setting up corporate Internet systems. I'm trying to do this myself and am getting swamped. I've convinced my boss I need people to meet our schedules and he's approved. I don't know where else to look. If any of you out there are interested or know of anyone who may be interested in working with a dynamic. forward- looking company in Northern New Jersey, please contact me at HFDK41A@prodigy.com immediately. I'm charged with taking my company live on the Internet and also helping a number of our corporate clients go live. We have been looking but haven't been able to turn up the talent. The money's good as are the benefits. We're located close to the NY Metropolitan area to benefit from its sphere of influence, but far enough away that it doesn't have to be all encompassing. Thanks for your help. -John Molnar From firewalls-owner Sat Dec 2 09:24:14 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA19088 for firewalls-outgoing; Sat, 2 Dec 1995 08:44:07 -0800 (PST) Received: from dg-webo.webo.dg.com (dg-webo.us.dg.com [128.221.131.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA19074 for ; Sat, 2 Dec 1995 08:43:58 -0800 (PST) Received: from banditos by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1) id AA14864; Sat, 2 Dec 1995 11:44:30 -0500 Received: by banditos.webo.dg.com (5.4R3.00/dg-s01) id AA14384; Sat, 2 Dec 1995 11:47:21 -0500 From: fwml@banditos.webo.dg.com (Firewall Mailing Lists Account) Message-Id: <9512021647.AA14384@banditos.webo.dg.com> Subject: Re: Need firewall to support enterprose private addresses To: blu@mc.com (Brian Utterback) Date: Sat, 2 Dec 1995 11:47:20 -0500 (EST) Cc: firewalls@greatcircle.com, dlehman@acm.org In-Reply-To: <9512020331.AA02418@beachball.mc.com> from "Brian Utterback" at Dec 1, 95 10:31:23 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk ... (stuff deleted) > First possibility, combine our Class C addresses. ... > My thought is to specify a subnet > mask of 255.255.254.0 and logically combine the four networks of 255 addresses This has nothing to do with firewalls, but personally I get a headache dealing with networks with non-standard netmasks. You might be able to get away with it, but it will probably require lots of care. ... > The problem I have is that I do not know which firewalls can do which of > these types of translations. Gauntlet used to be able to do this via the > application gateway route, but with the semi-transparent proxies they > have developed, I do not know if this is still the case. ... > Which firealls support use of enterprise private addresses? ... We resell both Gauntlet and Raptor. Either will be able to handle these addresses. Transparency does not affect the handling of RFC1597 addresses. The only case that I can think of where transparency would degrade functionality is where you were using illegal addresses inside which were duplicated on the internet. At least one firewall I know of can handle the case where you are trying to connect to a legal internet address and were using the same address inside. But this illegal address support only works using non-transparent proxies. The biggest caveat in going from a combo filter/application gateway firewall config to a pure application gateway is application support. If your internal users are using applications without proxy support then you may have a problem. Both Raptor and Gauntlet offer generic type proxy (plug-gw and GSP) but these may not work for all applications. From firewalls-owner Sat Dec 2 10:54:14 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA24602 for firewalls-outgoing; Sat, 2 Dec 1995 10:30:58 -0800 (PST) Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id KAA24594 for ; Sat, 2 Dec 1995 10:30:54 -0800 (PST) Received: from maestro.Maestro.COM by relay6.UU.NET with SMTP id QQzskg18299; Sat, 2 Dec 1995 13:31:45 -0500 (EST) Received: by maestro.Maestro.COM (4.1/MAESTRO-0.1/07-03-93) id AA25094; Sat, 2 Dec 95 13:22:39 EST Date: Sat, 2 Dec 1995 13:22:38 -0500 (EST) From: Sick Puppy Subject: Re: Encryption To: firewalls@GreatCircle.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk David P., that was a real good lead you gave me on Raptor for client/server encryption and firewalls. Thank you very much. Please consider yourself to have been electronically licked (on any body part of your own choosing). Sick Puppy, the Cat_Eating_Dawg Poet -=( running along the lake shore, listening to the loons, )=- -=( peeing on the bushes, on a windy afternoon. )=- From firewalls-owner Sat Dec 2 11:24:14 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA25622 for firewalls-outgoing; Sat, 2 Dec 1995 11:19:53 -0800 (PST) Received: from colt.milepost.com (colt.milepost.com [164.57.50.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA25617 for ; Sat, 2 Dec 1995 11:19:49 -0800 (PST) Received: (from phil@localhost) by colt.milepost.com (8.6.12/8.6.9) id NAA20821; Sat, 2 Dec 1995 13:20:15 -0600 From: Phil Howard Message-Id: <199512021920.NAA20821@colt.milepost.com> Subject: Re: SDI etc. (3of3) To: PADGETT@hobbes.orl.mmc.com (A. Padgett Peterson, P.E. Information Security) Date: Sat, 2 Dec 1995 13:20:15 -0600 (CST) Cc: firewalls@GreatCircle.COM In-Reply-To: <951202100937.20219446@hobbes.orl.mmc.com> from "A. Padgett Peterson, P.E. Information Security" at Dec 2, 95 10:09:37 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > Am a bit confused here. How is this different from challenge/response except > that instead of an unpredictable challenge, you are exchanging a very > predictable (and spoofable) time hack that is used to develop the response ? > > I mean "let's synchronize our watches" went out as soon as earpiece > communicators (like the SS wears) became available. My question still remains, how do we make "syncronize our watches" itself secure? From firewalls-owner Sat Dec 2 13:54:14 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA27941 for firewalls-outgoing; Sat, 2 Dec 1995 13:27:11 -0800 (PST) Received: from denver.ssds.com (denver.ssds.com [134.127.16.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA27936 for ; Sat, 2 Dec 1995 13:27:06 -0800 (PST) Received: from baltimore.ssds.com (baltimore.ssds.com [134.127.34.1]) by denver.ssds.com (8.6.9/8.6.9.SSDSnet-hub) with ESMTP id OAA23444; Sat, 2 Dec 1995 14:27:58 -0700 Received: (from mam@localhost) by baltimore.ssds.com (8.6.9/8.6.9.SSDSnet-site) id QAA14734; Sat, 2 Dec 1995 16:27:56 -0500 Date: Sat, 2 Dec 1995 16:27:55 -0500 (EST) From: Mike Malik -- Dover DE X-Sender: mam@baltimore To: Alex Eveleigh cc: firewalls@GreatCircle.COM Subject: Re: Security of Leased Lines In-Reply-To: <0bf2c6c0@cornelius.scp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Fri, 1 Dec 1995, Alex Eveleigh wrote: > > I am interested in getting some feedback on how difficult it would be > for someone to tap a leased line for a network connection and what > possible defenses there are to reduce the risk of information > transported on leased lines being monitored. > > Thanks in advance, > > Alex > Yes you can tap the line ! The only defense I know of is to encrypt the data before you put it on the line. Without getting into a long discussion about the ways it can or can not be done why not stop and ask what the data you are sending accross the wire is actually worth to your company. I would use that answer to drive the level of security I chose. Mike ( ( | ( Mike Malik (mam@ssds.com) ) ) (| ), inc. 9841 Broken Land Parkway,Suite 100 business driven Columbia, MD 21046 technology solutions 410-381-4313 FAX: 410-381-2170 From firewalls-owner Sat Dec 2 14:24:14 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA29195 for firewalls-outgoing; Sat, 2 Dec 1995 14:15:13 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA29160 for ; Sat, 2 Dec 1995 14:15:06 -0800 (PST) Received: from rcooper.the-wire.com (rcooper.the-wire.com [198.53.159.74]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id RAA14763; Sat, 2 Dec 1995 17:15:10 -0500 Received: by rcooper.the-wire.com with Microsoft Mail id <01BAC0D9.A85CCC00@rcooper.the-wire.com>; Sat, 2 Dec 1995 17:14:37 -0500 Message-ID: <01BAC0D9.A85CCC00@rcooper.the-wire.com> From: Russ Cooper To: "'Tim Williams'" Cc: "firewalls@GreatCircle.COM" Subject: RE: A1 Systems? Date: Sat, 2 Dec 1995 17:14:35 -0500 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk "...in the truly commercial environment it is always about functionality until something really goes south (your hard disk gets wiped or someone's little program sends the boss's little black book to his wife via email)...." My experience has been that Firewalls are no different than a Life Insurance Policy. Someone with a net worth of $250,000 might buy $10 million worth of insurance, it makes them feel better. When the first premium payment is deducted from their account, however, they tend to be more realistic. The majority of commercial sites that I have visited regarding Internet Connectivity want what everyone always wants, as much as they can get for as little as possible. Most of my potential customers are shops with a single mainframe and many PC's (or Macs if it makes you feel better). They want to be on the Internet now, usually because their network is already on the Internet through one, or many, phone connections. We talk about the cost of the dedicated connection, the router, the web server, everything is going just fine, money is no object....then we bring everything to a grinding halt and talk about security. Boom, $20K, $30k, whatever. This is the interesting part. Sure, they agree, "we need to have security...but isn't there some cheaper alternative?". Yeah, like Uninsured Drivers Insurance??? Assurance is a great thing, its needed, and desired. Security is great stuff, its needed, and desired. Unfortunately for Mr./Ms. Firewall Customer, to get what they want they have to pay far more than they expected. I'm not saying that today's products are over-priced, or that they are not worth every penny they cost. But the average mid-sized customer just isn't prepared for the impact of the quote. As we all know, my $8000 IBM PC-XT isn't worth $1.50 today, and to get its functionality I can pay $500 and get 30 times the processing power. Hopefully Mass America will get the security feeling in such a big way that the same cost savings can be seen in this field too. There's a lot of folks out there just dying to buy JOKE (Just OK, eh?) products that will satisfy an extremely limited scope. Cheers, Russ Cooper, Senior Internet Integration Engineer SHL/Computer Innovations (now an MCI company) RCooper@the-wire.com or RWCooper@shl.com ? where do you wanna go to get the money to go to where you wanna go today ? From firewalls-owner Sat Dec 2 19:24:14 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id TAA04402 for firewalls-outgoing; Sat, 2 Dec 1995 19:14:01 -0800 (PST) Received: from northshore.ecosoft.com (northshore.ecosoft.com [192.233.85.129]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id TAA04397 for ; Sat, 2 Dec 1995 19:13:56 -0800 (PST) Received: from [198.115.179.212] (slip-3-12.shore.net) by northshore.ecosoft.com with SMTP id AA28714 (5.67a/IDA-1.5 for ); Sat, 2 Dec 1995 22:14:40 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 2 Dec 1995 23:21:08 -0500 To: firewalls@greatcircle.com From: vin@shore.net (Vin McLellan) Subject: SDI's Time-Synched SecurIDs Sender: firewalls-owner@GreatCircle.COM Precedence: bulk A (true) tale of a fragile token: I recently spent an afternoon with a Wizard, one of the true IP gurus; a guy whose practical scholarship has intrigued and educated me for years. At one point he pulled a plastic tape-cassette case out of his backpack, to display the C/R token he carries. The cassette case, he explained, allowed him to avoid banging the token keys and accidentally deprogramming the card. This C/R token was one of the ones which has two batteries -- supposedly to keep memory live with one, while the other battery is being replaced. Unfortunately, explained the Wiz, it's hard to get one battery out without nudging the other, which can wipe the memory. Twice he's had occasion to change a battery, he said, and both times he accidentally wiped the token. -- -- -- -- Balking only slightly (and wholly as a matter of form;-) I concede to Padgett Peterson that duping software is _a lot_ cheaper than manufacturing hardware. >Real bottom line is that where tokens are sufficient, the cost advantages >of soft tokens are so compelling as to be a no-braner. If the same software >on the host side can be used for 2,000 home access points and I only need >200 hardware tokens for travellers at risk, the cost is much easier to >justify than 2200 hardware tokens. Yet, just to be contrary, let me warn that a myopic glance at the relative cost of a token and/or a software pseudo-token is only part, maybe a small part, of the whole story. (Authentication is, after all, a _system_ purchase; particularly for a major Enterprise buy.) This is marketing territory, foreign turf to most security pros, but I have a gut level appreciation of the fact that real cost and billed cost are highly variable, particularly in sw. If you get the "soft toke" for free -- Padgett's 10% of a "high-priced" $50 token is only $5 per -- you'll be carrying a commercial vendor's overhead and profit in the price of the token-management software. Either now, or in planned price-hikes down the road, after the vendor wins market share. (S/key and OPIE are free, after all -- but despite years of talk, the S/key users can't get their OTP calculator designed into a smart card.) I suggest that future token/authentication system sales may have less to do with the bells, whistles, or even cost (!) of the token, than in whether: _the vendor can support client/server networks effectively and dependably, or _the vendor's client code is easily accessed by (or has been integrated into) a wide variety of popular network components, or _the token database in the access control module is robust, relational... and accessible via SQL for active links with other corporate RDBS (particularly Personnel.) None of that, however, is to cast doubt on Padgett's claim that "soft tokes" will have a major role in the security spectrum that is typical of any large organization. I still think there is an issue of relative security (and will be for SDI's promised "soft tokes" too.) Padgett's suggestion that an encrypted disk on a soft-toke-loaded PC is the equivalent of a physical HHA is intriguing, but ultimately unpersuasive. >True there is a lot of debate as to whether you give up >some security when a soft token is in use over a hardware token. It >is my position that if full disk encryption is in use (a component not >normally discussed in this light), there is no additional vulnerability. There is a lot of hard-won experience compressed in the classical formula for a security token: something physical, assigned to an individual, & difficult to counterfeit. The mobile and pocketable nature of a HHA add immeasureably to their security in praxis. (I do bow to Padgett's experience where he explained that a secure "Pin-keyed" design for an all-software pseudo-token is feasible. His explanation is thought-provoking; I learned something new. Yet, out of habitual cynicism -- mind you, I have a collection of busted crypto algorithms off products from major firms -- I will continue to worry about that too.) All of the above being true, I'd still recommend clients buy "soft tokes" -- if the software that supports them would also support my favorite physical tokens and otherswise meet corporate needs. (And frankly, it wouldn't bother me at all if my soft-toke was C/R.) I've always argued for a spectrum of security options (with costs reflecting relative security.) Some privileges are too important or too powerful to be granted on the basis of _any_ OTP token. I'd want some separation of duties and joint responsibility for others -- like those two-party NSA crypto algorithms. For some, -- like access to a key-escrow Master key --I'd like the sworn witness of four US Supreme Court Justices, televised live. (Makes me wonder if we may see different classes of user access -- different databases, e.g. -- for people who's access level will be limited by which type of token they are given. I don't see MLS in the real world, but I do see different grades of data access; some tokens more limited than others.) >But the end-point I have been seeking for years is not to just use tokens to >authenticate users to hosts but to use then as key management devices for >creation of secure channels that also authenticate both host and user to >each other. From your lips to The Lord's ear! (Speaking of Ears in the sky: Ft. Meade, you listening too??) I couldn't agree more! And _whichever_ token vendor leads us into it will earn my gratitude. >With TS I read six digits off the card & type 12 digits into the screen >(6 ID & 6 response). Press enter. 13 keystrokes. Delta four whole >keystrokes. If this makes a difference to anyone, they are not really >doing anything (opinion). In deference to Mr. Bosen and others who echoed Padgett that the keystroke delta between TS and C/R is slight, I suppose I should admit that my reference group was one Crusty Old Fart and several of my arthritic mates on furlough from a Home for burnt-out hippies. Not the type to race a stopwatch. (So maybe the word "minutes" should have read seconds;-) That's the good news. The _bad_ news is that I've also talked to hundreds of real folks and they _also_ prefer not to tap numbers into a credit card keypad. Or to start at the keyboard, go to the token keypad, then back to the keyboard. Many have days when, unavoidably, they're on and off the net -- and these little aggravations multiply. >Other difference is that fixed id is sent in clear with TS, PIN is >kept secret with C/R. I think we're soon going to have to break down these discussions into two sub-text categories: products which have made the paradyme leap into the client/server architecture, and those which have not. In the case of SDI, they've had SecurIDs on C/S nets for four-plus years, with a protocol which DES encrypts the packets containing the authentication call -- and yes, there are parts of that protocol (in particular, the mutually authentication of both ACE/Client and ACE/Server) which echo the mechanics of C/R. No big deal. Indeed, it would only surprise me a little if SDI's promised "soft toke" was itself C/R. I know they tested one for years. (Actually, maybe it would. SDI has all these patented little tricks with TS which will eventually become products, and a time-insensitive "soft toke" would be unable to take advantage of them.) In typically intriguing "PS" on one message, Padgett added: > know the date 36 months from issue one of my TS cards will stop working, > the C/R one I have had since 1990 just keeps on ticking. Of course it > only needs to be on for 20 seconds a day. Padgett: Any idea what sort of logic went into MMC's purchase of the 3-year SecurID, rather than the cheaper 4-year SecurID? (It is a very common corporate choice, presumably because the purchaser gets some advantage from the three-year turnover, despite the added cost per year.) And if you had 20,000 SecurIDs on a server, as some SDI customers do? Would you feel better being able to plan a date-certain transition from one token to the next? Or would you -- in a mission critical environment -- trust that most users could manage the battery change without deprogramming the calculator? Suerte, _Vin Vin McLellan +The Privacy Guild+ 53 Nichols St., Chelsea, Ma., USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*> From firewalls-owner Sun Dec 3 00:24:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id AAA08952 for firewalls-outgoing; Sun, 3 Dec 1995 00:19:16 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id AAA08947 for ; Sun, 3 Dec 1995 00:19:10 -0800 (PST) Message-Id: <199512030819.AAA08947@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA291018778; Sun, 3 Dec 1995 19:19:38 +1100 From: Darren Reed Subject: Re: your mail To: phil@colt.milepost.com (Phil Howard) Date: Sun, 3 Dec 1995 19:19:38 +1100 (EDT) Cc: hroller@c2.org, firewalls@GreatCircle.COM In-Reply-To: <199511270041.SAA07114@colt.milepost.com> from "Phil Howard" at Nov 26, 95 06:41:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In some mail from Phil Howard, sie said: [...] > I would like to know which packet filter routers have the capability > to do more than just linear testing sequences. The ability to branch > to labels and/or call subroutines would be great. That way, for instance, > instead of the restricted set of actions for a match being permit or deny, > you could have another set of filter tests be applied. You might want > one set of hosts allowed through for DNS, another set for FTP, another > set for HTTP, another for TELNET, another for.... I don't recall an answer to this, but I believe Morning Star's Express stuff will work this way. Depending on if a packet matches one rule, you can add another filter to the frey. Also have a look at "An Architecture for Advanced Packet Filtering", (Andrew Molitor) prsented at this year's 5th Usenix Security Symposium. I don't particularly like the way `rules' are expressed here, however. You should be able to find this under the USENIX web page. The description you give on wanting different hosts depending on your service can be solved by just thinking about writing your rules in a different way. Admitadly, there isn't much flexibility for that, at present. Might I ask which brand you're using ? darren From firewalls-owner Sun Dec 3 00:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id XAA08439 for firewalls-outgoing; Sat, 2 Dec 1995 23:55:32 -0800 (PST) Received: from riverside.mr.net (Riverside.MR.Net [137.192.2.5]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id XAA08434 for ; Sat, 2 Dec 1995 23:55:28 -0800 (PST) Received: from msp1-15.nas.MR.Net by riverside.mr.net (8.6.12/SMI-4.1.R931202) id BAA15692; Sun, 3 Dec 1995 01:56:19 -0600 Received: by msp1-15.nas.MR.Net with Microsoft Mail id <01BAC122.4FEA1660@msp1-15.nas.MR.Net>; Sun, 3 Dec 1995 01:54:41 -0600 Message-ID: <01BAC122.4FEA1660@msp1-15.nas.MR.Net> From: Paul Merenbloom To: "firewalls@greatcircle.com" Subject: RE: selection criteria? Date: Sun, 3 Dec 1995 01:34:08 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In response to my _open ended_ query, MJR, commented... > That put features, price, vendor reputation, and security > all at the top. Then there's everything else. > Moubray, Steve writes: > >Criteria # 1 is your needs. > >Criteria # 2 is support. > >Criteria # 3 reputation and staying power. This raises an important issue -- "reputation and staying power" -- = recognizing that lots of folks on this list *work* (or at least collect = a paycheck ) from F/W vendors, and/or are consultants -- how do you = decide _who_ has staying power? Reputation in this sector could be as = simple as your last win or failure (eg product flop) but longevity? = Hmmm.... ---------- From: Marcus J. Ranum[SMTP:mjr@iwi.com] Sent: Friday, December 01, 1995 5:09 PM To: firewalls@greatcircle.com Subject: selection criteria? Paul Merenbloom drops a small bomb: >What would you consider the top 5-10 issues? How does price >sensitivity (or lack thereof) affect your rankings / issues? On what >basis would (or have) you made your decisions (or guided others)? I played a naughty little game at a conference recently where I polled the room by show-of-hands as to what were the important things they looked for in firewalls. Features, price, and vendor reputation were pretty much the top categories. I'd cheated and left "security" off my list and I thought I was going to get away with it until someone flagged me when I asked "are there any criteria I forgot to put on the list...?" That put features, price, vendor reputation, and security all at the top. Then there's everything else. Moubray, Steve writes: >Criteria # 1 is your needs. >Criteria # 2 is support. >Criteria # 3 reputation and staying power. 'nuff said. :) mjr. From firewalls-owner Sun Dec 3 01:24:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id BAA09790 for firewalls-outgoing; Sun, 3 Dec 1995 01:12:28 -0800 (PST) Received: from hosaka.smallworks.com (hosaka.SmallWorks.COM [192.207.126.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id BAA09767 for ; Sun, 3 Dec 1995 01:12:21 -0800 (PST) Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA25536; Sun, 3 Dec 1995 03:12:49 -0600 Date: Sun, 3 Dec 1995 03:12:49 -0600 From: jim@SmallWorks.COM (Jim Thompson) Message-Id: <9512030912.AA25536@hosaka.smallworks.com> To: avalon@coombs.anu.edu.au, phil@colt.milepost.com Subject: Re: your mail Cc: charisse@SmallWorks.COM, firewalls@GreatCircle.COM, hroller@c2.org, jamie@tivoli.com, jes@SmallWorks.COM, steve@SmallWorks.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >In some mail from Phil Howard, sie said: >[...] >> I would like to know which packet filter routers have the capability >> to do more than just linear testing sequences. The ability to branch >> to labels and/or call subroutines would be great. That way, for instance, >> instead of the restricted set of actions for a match being permit or deny, >> you could have another set of filter tests be applied. You might want >> one set of hosts allowed through for DNS, another set for FTP, another >> set for HTTP, another for TELNET, another for.... > >I don't recall an answer to this, but I believe Morning Star's Express >stuff will work this way. Depending on if a packet matches one rule, >you can add another filter to the frey. I answered Mr. Howard privately, but Netgate already does the 'branch to labels' bit, and we're working out the kinks in the rest of what you describe. Sorry for the plug, but I'm seeing an increased interest in this type of thing (non-linear filter sets). Jim From firewalls-owner Sun Dec 3 06:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA15711 for firewalls-outgoing; Sun, 3 Dec 1995 06:36:19 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA15706 for ; Sun, 3 Dec 1995 06:36:15 -0800 (PST) Date: Sun, 3 Dec 1995 9:37:08 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951203093708.2021bb9d@hobbes.orl.mmc.com> Subject: A1 systems Sender: firewalls-owner@GreatCircle.COM Precedence: bulk To those who have not been out of their caves lately - I meant Rexx as in "Toy Story", not as in IBM. Warmly, Padgett From firewalls-owner Sun Dec 3 07:25:54 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA16122 for firewalls-outgoing; Sun, 3 Dec 1995 06:56:55 -0800 (PST) Received: from denver.ssds.com (denver.ssds.com [134.127.16.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA16117 for ; Sun, 3 Dec 1995 06:56:51 -0800 (PST) Received: from freke.ssds.com (rem_den29.ssds.com [134.127.122.29]) by denver.ssds.com (8.6.9/8.6.9.SSDSnet-hub) with SMTP id HAA29361 for ; Sun, 3 Dec 1995 07:57:42 -0700 From: Chris.Liljenstolpe@SSDS.com (Chris Liljenstolpe (Swanson) - SSDS) To: firewalls@GreatCircle.COM Subject: Re: SDI's Time-Synched SecurIDs Date: Sun, 03 Dec 1995 14:55:56 GMT Organization: SSDS, Inc. Reply-To: Chris.Liljenstolpe@SSDS.com Message-Id: <30c1b884.72860719@denver.ssds.com> References: In-Reply-To: X-Mailer: Forte Agent .99c/16.141 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Greetings, For those of you who have mentioned liking a two-man rule in tokens, if you have not already looked at the CryptoCard, you may want to do so. This card offers an SNK type mechanism with 1-3 keys. However, you can also set it up with a "split 1 key" where two different security officers each enter a key into the server and card. The card and server then combine those two keys into one key. This keeps the card safe even if one security officer is compromised. Regards, -Chris ( ( | ( Chris Liljenstolpe ) ) (| ), inc. SSDS, Inc; 8400 Normandale Lake Blvd. Suite 993 business driven Bloomington, MN 55437; technology solutions TEL 612.921.2392 FAX 612.921.239 Um Yah Yah! From firewalls-owner Sun Dec 3 07:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA15629 for firewalls-outgoing; Sun, 3 Dec 1995 06:31:56 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA15617 for ; Sun, 3 Dec 1995 06:31:49 -0800 (PST) Date: Sun, 3 Dec 1995 9:32:42 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951203093242.2021bb9d@hobbes.orl.mmc.com> Subject: re: SDI's Time-Synched SecurIDs and other things that go "tick". Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Vin rites: > A (true) tale of a fragile token: Oh I agree and a SecurID token is the one which rested in my wallet while I went white-water rafting in Alaska (during a heat wave - saw all of the elusive "Big Four" at Denali mostly speadeagled on what was left of the ice trying to keep cool - managed to promote the only portable fan in the hotel - us Floridians know what to do 8*). It survived but the credit card in the next slot broke. >The cassette case, he >explained, allowed him to avoid banging the token keys and accidentally >deprogramming the card. Have never had that problem but I do not use a WatchWord, my SecurID is in a silver plastic folder and my SafeWord is in an identical black plastic one. Both are behind clear plastic dividers so they do not have to be removed from use - I push the SW keys right through the plastic. >Twice he's had occasion to change a battery, he said, and both times he >accidentally wiped the token. Have not experienced that but is a matter of mechanical design/battery life. - five years so far on a battery says that whenever a "low battery" indication appears, I'll just trade it in. > Yet, just to be contrary, let me warn that a myopic glance at the >relative cost of a token and/or a software pseudo-token is only part, maybe >a small part, of the whole story. (Authentication is, after all, a >_system_ purchase; particularly for a major Enterprise buy.) Absolutely ! > This is marketing territory, foreign turf to most security pros, Will disagree with that, an essential part of security *is* marketing particularly since it is something managers/executives are not paid to understand it. At least we are approaching the critical point where, like General Patton on logistics (usual memory disclaimer), executives are beginning to say "I don't know what it is, but I want some." >Padgett's suggestion that an encrypted disk on a soft-toke-loaded PC is the >equivalent of a physical HHA is intriguing, but ultimately unpersuasive. It is when you consider the overall system security posture: the system is now as secure as the user (particularly if the PIN is not stored on the machine and is used to generate the key), something the vendor's have not given much thought to. *I do not know of a single token vendor who provides the capability for a "duress code" into their product.* Good locks on cars caused carjackings (the driver became the weak point). Several years ago when I had the opportunity to play with a new Pontiac with the remote everything fob, I suggested that they add a button that 20 seconds after pressing, everything would shut down (give the driver sufficent time to leave the vicinity). Palm-print biometric devices are required to check for a pulse (reason for this is left to the imagination). I conside the safety of employees as much a responsibility of security as the protection of assets (employees ARE assets). > I've always argued for a spectrum of security options (with costs >reflecting relative security.) Some privileges are too important or too >powerful to be granted on the basis of _any_ OTP token. I'd want some >separation of duties and joint responsibility for others -- like those >two-party NSA crypto algorithms. For some, -- like access to a key-escrow >Master key --I'd like the sworn witness of four US Supreme Court Justices, >televised live. Agree 100%. Generally this calls for a third factor, *where* you are. >I don't see MLS in the real world, but I do see different >grades of data access; some tokens more limited than others.) Do not necessarily see any need for more than one hard/soft token, would just add complexity and logistical problems. Permission levels granted to the user/token/location system is Good Enough (C). > Padgett: Any idea what sort of logic went into MMC's purchase of >the 3-year SecurID, rather than the cheaper 4-year SecurID? (It is a very >common corporate choice, presumably because the purchaser gets some >advantage from the three-year turnover, despite the added cost per year.) Well, you just said the reason: "MMC". Today we are Lockheed-Martin. Last year we absorbed a big chunk of GE. In the last five years my worldview has gone from 14,000 employees in Orlando (voted Computer Security Program of the Year by CSI in 1992) to 170,000 employees worldwide. We must accomodate heritage systems in our move toward a centralized security system. Is not easy, is not the best of all possible worlds, just is. My participation here is part of a vision of where we must get to, not where we are. One of the best compliments I have had came from a corporate VP who said "I don't know what the h*ll he is doing, but know we will need it in a year." To be blunt, what I am doing is marketing, marketing concepts and mechanisms to make my job easier - am lazy you know 8*). > And if you had 20,000 SecurIDs on a server, as some SDI customers >do? Would you feel better being able to plan a date-certain transition from >one token to the next? Or would you -- in a mission critical environment -- >trust that most users could manage the battery change without deprogramming >the calculator? And would you want a date-dying CMOS battery ? Personally, I want a token to "be all that it can be". "date certain" just adds complexity and I like a close shave. Warmly, Padgett From firewalls-owner Sun Dec 3 09:24:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA19787 for firewalls-outgoing; Sun, 3 Dec 1995 09:02:01 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA19775 for ; Sun, 3 Dec 1995 09:01:52 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id MAA09797 for ; Sun, 3 Dec 1995 12:02:18 -0500 Date: Sun, 3 Dec 1995 12:02:18 -0500 Message-Id: <199512031702.MAA09797@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@GreatCircle.COM From: Anton J Aylward Subject: Re: A1 Systems Sender: firewalls-owner@GreatCircle.COM Precedence: bulk 1. Define matrix: Rows: Sufficient, Not Sufficient Cols: Necessary, Not Necessary Depth: Operating Environment Requirements. 2. Fill in. 3. Examine WRT products. Hmmm. 4. Stop arguing in circles. /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Sun Dec 3 09:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA19888 for firewalls-outgoing; Sun, 3 Dec 1995 09:09:08 -0800 (PST) Received: from denver.ssds.com (denver.ssds.com [134.127.16.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA19883 for ; Sun, 3 Dec 1995 09:09:04 -0800 (PST) Received: from freke.ssds.com (rem_den29.ssds.com [134.127.122.29]) by denver.ssds.com (8.6.9/8.6.9.SSDSnet-hub) with SMTP id KAA09276; Sun, 3 Dec 1995 10:08:21 -0700 From: Chris.Liljenstolpe@SSDS.com (Chris Liljenstolpe (Swanson) - SSDS) To: "A. Padgett Peterson, P.E. Information Security" Cc: firewalls@greatcircle.com Subject: Re: SDI's Time-Synched SecurIDs and other things that go "tick". Date: Sun, 03 Dec 1995 17:06:33 GMT Organization: SSDS, Inc. Reply-To: Chris.Liljenstolpe@SSDS.com Message-Id: <30c1d88b.77861231@denver.ssds.com> References: <951203093242.2021bb9d@hobbes.orl.mmc.com> In-Reply-To: <951203093242.2021bb9d@hobbes.orl.mmc.com> X-Mailer: Forte Agent .99c/16.141 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Sun, 3 Dec 1995 9:32:42 -0500 (EST), "A. Padgett Peterson, P.E. Information Security" wrote: ( [SNIP] (> (>It is when you consider the overall system security posture: the system is (>now as secure as the user (particularly if the PIN is not stored on (>the machine and is used to generate the key), something the vendor's have (>not given much thought to. *I do not know of a single token vendor who (>provides the capability for a "duress code" into their product.* (> However, I know of one who is adding it (although I can't say who at the time). Regards, -=Chris ( ( | ( Chris Liljenstolpe ) ) (| ), inc. SSDS, Inc; 8400 Normandale Lake Blvd. Suite 993 business driven Bloomington, MN 55437; technology solutions TEL 612.921.2392 FAX 612.921.239 Um Yah Yah! From firewalls-owner Sun Dec 3 10:24:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA19788 for firewalls-outgoing; Sun, 3 Dec 1995 09:02:03 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA19776 for ; Sun, 3 Dec 1995 09:01:53 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id MAA09755; Sun, 3 Dec 1995 12:00:49 -0500 Date: Sun, 3 Dec 1995 12:00:49 -0500 Message-Id: <199512031700.MAA09755@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "A. Padgett Peterson, P.E. Information Security" From: Anton J Aylward Subject: Re: Security of leased lines Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Alex rites: > I am interested in getting some feedback on how difficult it would be > for someone to tap a leased line for a network connection I have before me as I write a copy of IBM's "Personal System News". Its a 36 page mini-magazine touting IBM, networking, and their products. On page 27, Hot Tip #3 is: Leased Line Service: Minimize the risk of your network being attacked. Although it espouses NetSP and Advantis, the context is one where its implying that a leased line is safer than a dialup line. Although that is never stated explicitly. What blows the whole thing out of the water, though, is the phrase "No need to purchase and maintian a firewall". It goes on, and the way things are worded it looks like the firewall is NOT at the customer premises. If this is the case, how does this add to the security? I have a client (this is Canada remember, but the same situation could occur in parts of the USA) where the "local loop" is nearly 1,000 km in length. CPE firewalls are a MUST! /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Sun Dec 3 10:36:36 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA19793 for firewalls-outgoing; Sun, 3 Dec 1995 09:02:12 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA19786 for ; Sun, 3 Dec 1995 09:02:00 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id MAA09804 for ; Sun, 3 Dec 1995 12:02:22 -0500 Date: Sun, 3 Dec 1995 12:02:22 -0500 Message-Id: <199512031702.MAA09804@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@GreatCircle.COM From: Anton J Aylward Subject: Firewalls for the rest of us (was Re: A1 Systems) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Visualize a graph if you will, two curves: A/x and B-(C/x) One curve is the value of what you want to protect, the other is what you are spending on protecting. You're plotting cost of security vs exposure. Somewhere the curves cross, your cost of righ and your cost of protection are in balance. [ Logic goes perfect protection cost infinite dollars, zero protection, zero dollars Zero protection means infinite exposure. Substitute currency symbol where appropriate. ] Basically, the intelligent approach is to invest in protection to a certain point. Beyond that, you decide to accept the risk. Or buy insurance. Maybe your insurance premium gets lowered if you show you are taking adequate measures to protect yourself. Think like an actuary! As technology progresses the variable A alters. As hacker techniques progress variables B and C alter. If A1 systems become as cheap next year as the existing firewalls are today, then they become the 'accepted reasonable precautions' of the industry - again to 'think like an actuary'. But then that has raised the accepted level of technology in general.... Now, lets introduce a bit of humour|realism :- Question: Will your A1 system protect against: a) Meteor Strike b) Change in Government c) Theft by Employee c) Fraud by officer of the company any better than the system I have in place right now? If not, then what do you suggest? /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Sun Dec 3 10:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA19830 for firewalls-outgoing; Sun, 3 Dec 1995 09:05:38 -0800 (PST) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA19818 for ; Sun, 3 Dec 1995 09:05:26 -0800 (PST) Received: by mycroft.GreatCircle.COM (8.6.10/SMI-4.1/Brent-950602) id JAA23458; Sun, 3 Dec 1995 09:05:24 -0800 Received: from psyche.the-wire.com(198.53.192.2) by mycroft via smap (V1.3mjr) id sma023454; Sun Dec 3 09:04:55 1995 Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id MAA09791; Sun, 3 Dec 1995 12:02:10 -0500 Date: Sun, 3 Dec 1995 12:02:10 -0500 Message-Id: <199512031702.MAA09791@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Peter Jeremy From: Anton J Aylward Subject: Re: chroot/setuid vs type enforcement Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 08:25 30/11/95 +1100, Peter Jeremy wrote: >I think a better approach would be to remove execute permission from >the writable portion of the address space. This means that you can't >install your own code. The best you can achieve is to `return' to >an unexpected location. This immediately limits the potential damage. >If you then nail exec(), the _system_ is fairly impervious. (You can >kill the application, but avoiding denial-of-service attacks is probably >impossible). I think a better approach would be to use machines which have separate stacks for parameters and return addresses..... ;-) I think compiling with static strings (and tables and so on) which are in 'code space' and code space is by definition unwritable (which isn't the case on X86machines because Microsoft uses self modifying code) should be a standard method of coding. This requires no physical changes and is well within the capabilities of the present technology. If the vendors chose to do it. But then recoding so that we don't have various strings and buffers in the stack frame is of the same order as changing the declarations of these strings, and look what it took to get some people to do that. More to the point, look at all who havn't. I'm begining to thin running LINUX on the SUNs makes a lot of sense ;-) /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Sun Dec 3 11:23:31 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA19765 for firewalls-outgoing; Sun, 3 Dec 1995 09:01:07 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA19760 for ; Sun, 3 Dec 1995 09:01:03 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id MAA09764; Sun, 3 Dec 1995 12:01:18 -0500 Date: Sun, 3 Dec 1995 12:01:18 -0500 Message-Id: <199512031701.MAA09764@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: peter@nmti.com (Peter da Silva) From: Anton J Aylward Subject: Orange Book Irrelevant (was: A1 Systems?) Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 09:40 1/12/95 -0600, peter@nmti.com (Peter da Silva) wrote: >> It's not about features, it's about assurance. >> Commercial computing is about features (represented as functionality) >> Therefore orange book is irrelevant to commercial computing. > >I have to say Marcus makes a good case. If assurance meant anything in the >commercial world MS-DOS would have been sidelined by 1984. > >(sigh) Indeed, Sigh! Feature selling - aka Bullet List selling (him what has the longest bullet list wins the sale) has come to dominate commercial computing. This is adequately demonstrated when the winning list beats out the competition with 'features' which are irelevant to the task being performed. (Is there a Dilbert cartton lurking there?) Features have no place in a firewall. Actually, they have no place in any product, if you subscribe to the old maxim "Its not a bug its a feature". Every additional feature is an opportunity for something to go wrong. For example, supose this whizz-bang firewall had SO MUCH POWER that it was a waste to use it just a filter mechanism. Lets implement a FTP server, and a WWW server on it as well. Whose? Well, the vendor's version of course. (E.g. is a HP T500 platform with HP/UX V9. See late CERT advisory for details.) Oh, and as FTP isn't suited to everyone's taste, lets allow the files which are FTP'able to be NFS mountable as well. And of course we have an X-Windows based configuration tool running on this platform as well. Hey, look at all we've added to the Feature List! I'm not disparaging HP here, its just I have a copy of that last advisory to hand and a client has a whole slew of T500s so I know how powerful they are. But it illustrates the point. As I've said before, as others before me have said, and we will all continue to say.... The more code you write, the more chance something can go wrong. The ONLY long term repeatedly proven metric of BUGS is the volume of code. A stripped kernel with the bare essential of application code is what's needed for a firewall, NOT a general purpose computing platform. [If enough people ask, I'll write up what's wroing with the way CHROOT() is implemented and how it should be done in a hardened kernal. Its simple and obvious once you see it.] But that's not why the Orange Book is irrelvant to commercial comptuing in the 1990's. Or not completely so. My list would begin with... We're no longer running as terminals connected to a single isolated mainframe. The military ideas of "need to know", "heirarchy" and cells don't apply in business. Can someone suggest more reasons our current rainbow approach is inapplicable? /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Sun Dec 3 11:24:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA20776 for firewalls-outgoing; Sun, 3 Dec 1995 10:07:39 -0800 (PST) Received: from northshore.ecosoft.com (northshore.ecosoft.com [192.233.85.129]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA20769 for ; Sun, 3 Dec 1995 10:07:35 -0800 (PST) Received: from [198.115.179.219] (slip-3-18.shore.net) by northshore.ecosoft.com with SMTP id AA20410 (5.67a/IDA-1.5 for ); Sun, 3 Dec 1995 13:08:12 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 3 Dec 1995 14:14:46 -0500 To: Chris.Liljenstolpe@SSDS.com From: vin@shore.net (Vin McLellan) Subject: Re: SDI's Time-Synched SecurIDs Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Chris Liljenstolpe noted that CryptoCard: >... offers an SNK type mechanism with 1-3 keys. However, you can also set it >up with a "split 1 key" where two different security officers each enter a key >into the server and card. The card and server then combine those two keys >into one key. This keeps the card safe even if one security officer is >compromised. I like that. Even if it is the sort of fandangle that security managers grin about but never buy or use. My compliments to Steve Seal in Ontario. Another good example of those smile-but-don't-buy features was the duress code Padgett mentioned: *I do not know of a single token vendor who >provides the capability for a "duress code" into their product.* Actually, SDI provided a duress code option for their SecurID for the first 3 or 4 years, if memory serves -- but I never heard of a single company using it. I think SDI quietly dropped it and no one noticed. (Maybe SDI would provide it as a special feature if requested. They have the code, and it's long since gone through their extended QA process.) Padgett also noted: >...a SecurID token is the one which rested in my wallet while >I went white-water rafting in Alaska.... It survived but the credit >card in the next slot broke. Next time you take an adventure vacation, ask SDI for one of their new "key fob" tokens. The SecurID card has gotten sturdier over the years, but the key fob allowed them to escape the bend-and-bust syndrome. It should survive even if you lose the raft, next time you go white water rafting;-) (I suggested they pass them out to the crew of "tunnel rats" working on the third harbor tunnel here in Boston, and then collect stats on the failure rates for an ad. But the SDI marketing department doesn't pay much attention to me. And I've got to admit, they've done fairly well without my guidance.) Suerte, _Vin Vin McLellan +The Privacy Guild+ 53 Nichols St., Chelsea, Ma., USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*> From firewalls-owner Sun Dec 3 11:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA23676 for firewalls-outgoing; Sun, 3 Dec 1995 11:40:01 -0800 (PST) Received: from gatekeeper.ddp.state.me.us (gatekeeper.ddp.state.me.us [141.114.130.70]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA23671 for ; Sun, 3 Dec 1995 11:39:57 -0800 (PST) Received: from localhost by gatekeeper.ddp.state.me.us (8.6.5/1.37) id OAA00421; Sun, 3 Dec 1995 14:35:08 -0500 Date: Sun, 3 Dec 1995 14:35:07 -0500 (EST) From: David Miller Subject: Re: Orange Book Irrelevant (was: A1 Systems?) To: Anton J Aylward cc: Peter da Silva , firewalls@greatcircle.com In-Reply-To: <199512031701.MAA09764@psyche.the-wire.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Sun, 3 Dec 1995, Anton J Aylward wrote: [various good points about feeping creaturism deleted] > [If enough people ask, I'll write up what's wroing with the way CHROOT() is > implemented and how it should be done in a hardened kernal. Its simple > and obvious once you see it.] OK, here's one request. How should chroot() be implemented? --- David Miller ---------------------------------------------------------------------------- It's *amazing* what one can accomplish when one doesn't know what one can't do! From firewalls-owner Sun Dec 3 12:09:57 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA19772 for firewalls-outgoing; Sun, 3 Dec 1995 09:01:27 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA19767 for ; Sun, 3 Dec 1995 09:01:21 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id MAA09771; Sun, 3 Dec 1995 12:01:31 -0500 Date: Sun, 3 Dec 1995 12:01:31 -0500 Message-Id: <199512031701.MAA09771@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Rick Smith From: Anton J Aylward Subject: Re: chroot/setuid vs type enforcement Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 14:23 1/12/95 -0600, Rick Smith wrote: >Regarding Marcus' specific example: chroot() is a pitiful thing. I >dislike any security mechanism that relies on an application to set >protections up correctly anyway. I think you're being a bit unreasonable. Unless we're talking about an embedded system, we have to rely on not just the OS, but the application and the complete operating environment. If you're talking about using a General Purpose Computing Platform (e.g. UNIX) then part of the deal is that it isn't going to do 'security' things unless the programmer programs it that way. And the environment is set up that way. For example, using one place 'croot()' is used, a proper anonymous FTP environment; the initd spawns the ftp server, which reads the config file. It then croots to /usr/ftp, and does the OS-specific set[e][ug]id() stuff. Under that directory is a _striped_down_ /etc, /bin, and if the vendors version of the OS requires it, a stripped down version of /dev. If there is no /bin/sh then causing a buffer overflow to exec that will acheive ziltch. This is setting up the environment properly. If you let people upload a /pub/sh which they can set the exec bit on and then exec, yes you have a problem, but this gets back to the configuration of the FTP server, which is an environment issue. Now if you object to the need for chroot/setid sequence, please explain how a) you have a general FTP server program for both 'real users' and anonymous users b) you are running this on a general purpose machine either in the DMZ or behind suitable firewall/filters/proxy c) you acheive a one-way (trapdoor) effect for the anonymous users. Point C is significant. It is what chroot() does even if you DON'T do the setid() stuff. Unless you've screwed up the way the kernel works (as I believe many versions of UNIX have, but as I've said, I have a bigoted attitude towards code quality), there is no way to address the "real" root once a chroot() has been performed. That is, if I'm running as root (aka UID==0) and do a 'chroot("/usr/ftp")' there is NO WAY I can go back to having the real root as my root, even if I continue to run as UID==0. As I said, you can't separate the OS, the application and the environment. [ As Peter da Silva points out, yes the Berkeley networking model means a socket open call bypasses the normal UNIX security model. A 'open("/dev/ftp/ports/23")' wouldn't, and of the /dev directory is stripped.... This is how it should have been done, conformant with the rest of the UNIX model. QED ] >> The *TRICK* is implementing the RIGHT code in the RIGHT >>place. > >How does the poor sap know if the code is right? He doesn't. Once upon a time there was enough of the UNIX community that could see and examine the source. We've had debates about "peer review" as it used to be called. It may not get everything first time, but its a lot better than STO. Now, the vedors have a closed shop. I run ELM on a client's HP-9000 and I don't know which version it corresponds to. They don't use the same numbering scheme as the publicly distributed version. I don't know what bugs have been fixed and they won't tell me. FTP is another example. Is the vendor running the stock (ATnT?) distribution version, bugs and all, the WU-FTP (which version) or their own hacked over version which may have introduced bugs and features no-one else knows about. I hate to say it, but this all adds up to a good argument for either running LINUX or stripping out just about every vendor supplied utility and replacing them with PD code. In some (e.g. SUN) environemtns this is easy enough. >Othewise you're just waiting for problems to emerge before fixing >them-- chasing the problems instead of getting in front of them. This has little to do with "Formal handwaving" or the lack of it and lot to do with Vendor's Attitudes. >If the Unix kernel >interface implemented an adequate protection model for what we're >doing (it doesn't, which is why we put in TE) then the Formal >Handwaving would provide an obvious benefit. I blame the early people at Berkeley for a lot. Like Peter da Silva points out, having the network calls bypass the convention of the file system devices is a case in point. The lets add SENDMAIL in its entirity, the "r" commands, lots of network library modules with buffer overflow problems.... [ I would suggest you dig out the oriignal code for VI from the early BSD tapes and compare it to something like ELVIS or STEVIE. ] >There's also the whole question of playing fast and loose with the >Unix kernel interface -- - as Berkeley did with the whole "socket" based network interface. Sorry if I'm belabouting the point, but this is a coutner example to the "RIGHT code in the RIGHT place". This was the WRONG CODE and the wrong conceptual model. All the worse since they already had the RIGHT CODE and the right conceptual model to deal with. Rick, its not that I disagree with you wholheartedly. I just think that you're ignoring some important issues. I think the people who built the original UNIX were very smart. I also think that a lot of mediocre talent has constructed some [baroque/riccoco] not so smart edifices on top of it. If you're smart enough, you can build it right. If not, you have to be humble enough to recognize it and rely on the use of formal methods. Example: Napoleon was a BRILLIANT general. Von Clausawitz observed humbly, and wrote the book which became the FORMAL METHODs for instructing military officers. But that doesn't mean that other BRILLIANT generals cannot lead troops to victory without an impact analysis, situation ananlysis, umpteen simulations, dangling Markov chains and other incantations and rituals of the modern military heriarchy. Perhaps the trick is to make the model so simple that it can be proven by inspection to be correct and secure. Didn't some say something like that? /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Sun Dec 3 15:26:00 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA01045 for firewalls-outgoing; Sun, 3 Dec 1995 15:16:31 -0800 (PST) Received: from uuneo.neosoft.com (uuneo.neosoft.com [206.109.1.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id PAA01040 for ; Sun, 3 Dec 1995 15:16:28 -0800 (PST) Received: from ris1.UUCP (ficc@localhost) by uuneo.neosoft.com (8.7.2/8.7.1) with UUCP id RAA14456 for GreatCircle.COM!firewalls; Sun, 3 Dec 1995 17:09:37 -0600 (CST) Received: by ris1.nmti.com (smail2.5) id AA28813; 3 Dec 95 17:40:09 CST (Sun) Received: by sonic.nmti.com; id AA31921; Sun, 3 Dec 1995 17:10:11 -0600 From: peter@nmti.com (Peter da Silva) Message-Id: <9512032310.AA31921@sonic.nmti.com.nmti.com> Subject: Re: chroot/setuid vs type enforcement To: anton@the-wire.com (Anton J Aylward) Date: Sun, 3 Dec 1995 17:10:11 -0600 (CST) Cc: jeremyp@gsms01.alcatel.com.au, firewalls@GreatCircle.COM In-Reply-To: <199512031702.MAA09791@psyche.the-wire.com> from "Anton J Aylward" at Dec 3, 95 12:02:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > I think a better approach would be to use machines which have > separate stacks for parameters and return addresses..... ;-) ...and for arrays and pointers (and arrays of pointers?) and structures and what do you do about a structure on the stack containing a buffer and a pointer to a function...? From firewalls-owner Sun Dec 3 16:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA03640 for firewalls-outgoing; Sun, 3 Dec 1995 16:52:32 -0800 (PST) Received: from iiu.my (its.iiu.my [161.142.64.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id QAA03635 for ; Sun, 3 Dec 1995 16:52:28 -0800 (PST) Received: by its.iiu.my (5.x/SMI-SVR4) id AA22588; Mon, 4 Dec 1995 08:43:50 +0800 Date: Mon, 4 Dec 1995 08:43:49 +0800 (MYT) From: Arman Ali Anwar X-Sender: aanwar@its To: firewalls@greatcircle.com Subject: Linux/freeBSD & Firewalls for a Newbw :-) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Greetings, I'm thinking of configuring a Linux system to do firewalling and other related task like run proxies etc. I would be grateful if you knowledgeble ( <- Great respect intended ) ones could enlighten me on the following points: 1) What software options to i have .. firewalls, accounting, logging ... 2) How secure is it compared to other commercial and freeware / shareware stuff ??? 3) What services should I turn off on scuh a host ( ftp , telnet ... udp type connections etc ) and what options are required ( in a way related to 1 ) 4) How does Linux measure up against freebsd or bsdi ... I happen to love LINUX but faer it was designed with speed in mind and not security ... 5) Oh, last but not leat, any advise in structureless form :-) Well, Thanks in advance, Kind regards, Arman Ali Anwar From firewalls-owner Sun Dec 3 17:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id RAA05098 for firewalls-outgoing; Sun, 3 Dec 1995 17:29:58 -0800 (PST) Received: from uuneo.neosoft.com (uuneo.neosoft.com [206.109.1.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id RAA05093 for ; Sun, 3 Dec 1995 17:29:54 -0800 (PST) Received: from ris1.UUCP (ficc@localhost) by uuneo.neosoft.com (8.7.2/8.7.1) with UUCP id TAA28785 for GreatCircle.COM!firewalls; Sun, 3 Dec 1995 19:18:30 -0600 (CST) Received: by ris1.nmti.com (smail2.5) id AA29199; 3 Dec 95 17:49:52 CST (Sun) Received: by sonic.nmti.com; id AA32251; Sun, 3 Dec 1995 17:19:52 -0600 From: peter@nmti.com (Peter da Silva) Message-Id: <9512032319.AA32251@sonic.nmti.com.nmti.com> Subject: Re: chroot/setuid vs type enforcement To: anton@the-wire.com (Anton J Aylward) Date: Sun, 3 Dec 1995 17:19:52 -0600 (CST) Cc: smith@sctc.com, firewalls@GreatCircle.COM In-Reply-To: <199512031701.MAA09771@psyche.the-wire.com> from "Anton J Aylward" at Dec 3, 95 12:01:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > I blame the early people at Berkeley for a lot. Like Peter da Silva > points out, having the network calls bypass the convention of > the file system devices is a case in point. At least they did something close to the right thing with UNIX domain sockets. The AT&T inter-process communication model is far worse: not only are you working in a new address space it's a single address space for the whole system... so our token name space and Oracle's token name space collided. They had to create a routine that took a file name and combined the st_rdev and st_ino for the file into a 32-bit value, so you got your organized name space again. Here's an idea for a workaround: in the chrooted environment socket() only accepts UNIX domain sockets, and you have something like plug-gw running between chrooted-/dev/tcp/mail and the outside world. And if it turns out the UNIX domain sockets don't see chroot() or something I'll scream... From firewalls-owner Sun Dec 3 18:24:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id RAA05432 for firewalls-outgoing; Sun, 3 Dec 1995 17:59:00 -0800 (PST) Received: from psychotic.communica.com.au (gw.communica.com.au [203.8.94.161]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id RAA05411 for ; Sun, 3 Dec 1995 17:58:47 -0800 (PST) Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id MAA26943; Mon, 4 Dec 1995 12:28:27 +1030 Received: by communica.com.au (4.1/SMI-4.1) id AA12697; Mon, 4 Dec 95 12:28:04 CDT From: newton@communica.com.au (Mark Newton) Message-Id: <9512040158.AA12697@communica.com.au> Subject: Re: Linux/freeBSD & Firewalls for a Newbw :-) To: aanwar@iiu.my (Arman Ali Anwar) Date: Mon, 4 Dec 1995 12:28:04 +1030 (CST) Cc: firewalls@GreatCircle.COM In-Reply-To: from "Arman Ali Anwar" at Dec 4, 95 08:43:49 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk [ I know I'm going to get flamed for this, because Linux weenies are even more virulent than Amiga weenies used to be, but I can't let this pass. ] Arman Ali Anwar wrote: > 4) How does Linux measure up against freebsd or bsdi ... I happen to love > LINUX but faer it was designed with speed in mind and not security ... Not quite -- It was designed with fun in mind, and the quantities of speed and security that it offers are largely side effects. I support a number of Linux systems professionally. As such, I have a number of observations which might be useful to you. In my professional opinion, people who use a UNIX system as a firewall generally either don't understand firewalls very well or don't have security at the forefront of their mind when evaluating their requirements. [ the following paragraph contains generalities which apply to what would seem to be a "large" number of Linux advocates. If anyone emails me to say that they've taken it personally, or that Linux users aren't really at all like my portrayal below because *they*, personally, are not like that I will laugh until I die. Thank you for your cooperation. ] Linux "firewalls" are a particular case in point, because a disproportionate number of the people who use them suffer from BOTH of the traits listed above. The average Linux user is a UNIX newbie who sometimes even lacks the skills necessary to tighten down a normal UNIX system, let alone a firewall. Additionally, *cost* is usually the main factor which steers someone into using Linux as a firewall ("Hey! We have a $75 386SX-25 motherboard; we can put some cheap memory, cheap disk and a cheap ethernet card on it and build ourselves a $500 firewall, instead of buying two Ciscos and a bastion host! Q00l, eh?"). The end result of this is a network which is "firewalled" (spit!) behind a Linux box with some packet filters. By necessity, the Linux box runs *actual net-accessible services* (heaven forbid!), which means that the filters need gaps -- Hence, the machine is at risk of being compromised next time, say, a new sendmail/smail bug which allows any user on the Internet to break root is uncovered (in which case a small shell script could, say, remove all the "firewalling" IP filters before allowing the attacker in through any port he wanted). Thus, whilst the sysadmin thinks his network is nicely hidden behind his packet-filtering Linux machine, he's really only buying himself a small amount of protection over and above what he'd have with a completely unfirewalled network. The Linux scheduler and VM system is also pathetic enough to make you not want to run services on the machine anyway, even though you essentially have no choice. When a Linux machine runs a CPU- and IO-intensive application (such as, for example, INN), it gets so stupidly bogged down in paging that it can't route packets! I've seen many centrally- located (network-wise) Linux machines get to the point where running INN's "expire" program almost completely locks out networking until the expire run has finished. The only solutions to this problem are to either rewrite the scheduler or install massive amounts of memory to make sure that the system doesn't get into heavy paging (meaning that at least 32Mb, but more usefully 48Mb or 64Mb of RAM is needed on a machine which does nothing but run sendmail, INN and a nameserver). On just about any other operating system I can think of, 16Mb is more than adequate for that role. The bottom line is that Linux has not been designed as a firewall -- It has been designed as an OS that gets run on a single-user workstation (NOT! a server, no matter how many glowing stories Linux advocates tell you about its performance -- Linus Torvalds himself admits that the Linux kernel's scheduler does not perform well under load). As an OS that runs on a single user workstation, it delivers quite phenomenal performance, and I would recommend it to anyone in that role. However, it is not now, nor will it ever be, a firewall. Normally a firewall evaluation involves comparing how the firewall stacks up above alternatives in terms of security, performance and cost. If you're using Linux as a firewall, you're more or less telling the world that you simply don't give a damn about the first two of those criteria. - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-373-2523 Communica Systems WWW: http://www.communica.com.au From firewalls-owner Sun Dec 3 20:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA09424 for firewalls-outgoing; Sun, 3 Dec 1995 20:30:40 -0800 (PST) Received: from switchblade.iwi.com (switchblade.iwi.com [137.39.156.214]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id UAA09419 for ; Sun, 3 Dec 1995 20:30:35 -0800 (PST) Received: (from mjr@localhost) by switchblade.iwi.com (8.6.9/8.6.9) id XAA14057 for firewalls@greatcircle.com; Sun, 3 Dec 1995 23:31:56 -0500 From: "Marcus J. Ranum" Message-Id: <199512040431.XAA14057@switchblade.iwi.com> Subject: Napoleon and Clausewitz To: firewalls@greatcircle.com Date: Sun, 3 Dec 1995 23:31:56 -0500 (EST) Reply-To: mjr@iwi.com Organization: Information Warehouse! Inc, Baltimore, MD URL: mjr's web page Phone: 410-889-8569 Coredump: Infocalypse Now!!! X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Anton J Aylward writes: >Example: Napoleon was a BRILLIANT general. Von Clausawitz observed humbly, >and wrote the book which became the FORMAL METHODs for instructing military >officers. But that doesn't mean that other BRILLIANT generals cannot lead >troops to victory without an impact analysis, situation ananlysis, umpteen >simulations, dangling [...] I have to jump on this one. Because Anton makes an absolutely fascinatingly apropos digression. And I can't pass up the opportunity to explain why, since it's very relevant to the discussion. :) It's a digression, and it's not apropos, but it's the first time I can legitimately combine a longtime interest in Napoleonic military history with Internet firewalls. :) Napoleon went beyond being a brilliant general. [For one thing, *ahem* don't demote the man, he was Emperor of The French. Generals worked for him.] Napoleon pushed forward the state of the art of military science for its era. He refined the doctrine of combined arms, building significantly on Frederick the Great's doctrine to make appropriate use of then-modern artillery operating in conjunction with infantry and cavalry. He also completely very effectively revamped the integration of his command structure and communications and intelligence. During the height of the empire, using internal semaphore systems, messages were passed across much of france in approximately 15 minutes. If there can be said to be a "first modern army" Napoleon created it, and in the process of doing so, he created the modern nation-state. What's the point? Read on. Von Clausewitz was a petty staff officer, who saw action from a distance during the russian campaign. While he saw a few shots fired in anger, he was a far cry from Napoleon, who led bayonet charges at Toulon, and fought in major engagements about once a month for 14 years. Clausewitz saw enough of war to realize that it is a messy business, and retired to a cushy job at the german war college, where he wrote his classical work, and spent the rest of his career engaging in battles of letters not bullets. Clausewitz never held a rank above divisional general, never conquered Europe, never crushed Italy, Austria, Prussia, and Spain under his heel, never commanded the largest army known to mankind at that time, and never lost it in Russia. :) He did, however, inspire a generation of Prussian staff officers, including Moltke and Von Schiefflein. What's the point? It's a perfect example of the difference between the theoretical practitioner, and the real expert who knows how to get something done. Clausewitz' "formal methods" of warfare brought on the dogmatic disaster of the WWI trenches, in which both sides failed to calculate that aggressive power in excess of the ability to move it safely made mobile warfare impossible. Napoleon would not have made such an error. Clausewitzian military philosophy has, perhaps, had the same kind of stultifying effect on military thought as the orange book has had on computer security. :) Obviously, I find the example of Napoleon to be rather a bit more inspiring the the example of a theoretical armchair general. Napoleon broke tracks. Clausewitz followed behind and nattered like Siskel and Ebert. Strive for greatness. mjr. From firewalls-owner Sun Dec 3 21:24:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA09995 for firewalls-outgoing; Sun, 3 Dec 1995 21:02:14 -0800 (PST) Received: from Fe3.rust.net (Fe3.rust.net [204.157.12.254]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id VAA09990 for ; Sun, 3 Dec 1995 21:02:10 -0800 (PST) Received: from mh-19.rust.net by Fe3.rust.net via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id AAA00118; Mon, 4 Dec 1995 00:08:35 -0800 Date: Mon, 4 Dec 1995 00:08:35 -0800 Message-Id: <199512040808.AAA00118@Fe3.rust.net> X-Sender: janken@rust.net X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Alex.Eveleigh@kellogg.com (Alex Eveleigh) From: janken@rust.net (Ken Stephens - Millennium Consulting) Subject: Re: Security of Leased Lines Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > I am interested in getting some feedback on how difficult it would be > for someone to tap a leased line for a network connection and what > possible defenses there are to reduce the risk of information > transported on leased lines being monitored. > > Thanks in advance, > > Alex > Next time you see an Ameritech Line Repair person, ask him/her how many wiring junction points they have between your facility and the CO. Then ask how many wiring closets between your data demark and the your building cable entrance. Now ask someone to provide the same questions to the Phone company at each of your other facilities. If the combined total of all tap points is greater than 100 you owe me a box of Corn Flakes. If its greater than a 1000 you owe me a case. If its less than 100 I will buy you lunch the next time I visit our Branch Office down there. The key is that each point can be tapped and all the lines in-between can be tapped. If the bad guys really want to know, your only defense is Point to Point encryption with physical security (door locks) inside your facility up to the point of encryption. My $.02. Ken [][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][] [] Ken Stephens email: Ken_Stephens@miconsulting.com [] [] Millennium Consulting http://www.rust.net/~janken/milconsu.html [] [] Janet Perry email: Janet_Perry@miconsulting.com [] [] Millennium Jewelry Collection www http://rust.net/~janken/index.html [] [] 28234 Diesing Drive Voice (810) 548-0152 [] [] Madison Heights, MI 48071 Fax (810) 548-0152 [] [][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][] From firewalls-owner Sun Dec 3 21:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA10256 for firewalls-outgoing; Sun, 3 Dec 1995 21:14:00 -0800 (PST) Received: from northshore.ecosoft.com (northshore.ecosoft.com [192.233.85.129]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id VAA10251 for ; Sun, 3 Dec 1995 21:13:54 -0800 (PST) Received: from [198.115.179.219] (slip-3-19.shore.net) by northshore.ecosoft.com with SMTP id AA01501 (5.67a/IDA-1.5 for ); Mon, 4 Dec 1995 00:14:39 -0500 X-Sender: vin@shore.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Dec 1995 01:21:11 -0500 To: firewalls@greatcircle.com From: Christopher Klaus (by way of vin@shore.net (Vin McLellan)) Subject: Stealth Scanning - Bypassing Firewalls/SATAN Detectors Sender: firewalls-owner@GreatCircle.COM Precedence: bulk An interesting warning issued Friday to subscribers of Chris Klaus' new "Alert" mailing list. -vbm Stealth Scanning - Bypassing Firewalls and SATAN Detectors ---------------------------------------------------------- Administrators need tools to find out what is going on in their network. Maybe an internal employee has installed a unauthorized web server and put proprietary information online allowing anyone to access it, how does an administrator find out that there is even a web server running on their network? Many administrators use tools called TCP Port scanners. These programs which try to connect to all possible ports on a machine find which services are running. This information gives a network administrator better ability to understand and be aware of how his or her network is configured. Unfortunately, this technology is a double-edge sword because intruders can scan other networks and be able to gather information that helps better mount an attack. The intruder now knows which machines are running and what services are available. TCP port scanning is built into shareware auditing tools, such as ISS (Internet Security Scanner) and SATAN. These tools were intended to help administrators correct security risks in their network, but unfortunately they are just as useful to the bad guys. Because TCP port scanning is like knocking on the door of many services, people have written tools like SATAN detectors which notify administrators when outside people are knocking on their network. This has made the administrator feel like they are getting a good alarm notice if a hacker decides to attack their network. Here is a problem that we want to educate people about and possibly come up with some better solutions to addressing this problem. Most of the TCP port scanning technology relies on making an established connection with a port to determine if it is active or not. Many of the SATAN/Port Scanning Detectors rely on this fact. They record the connections and if a connection happens to a wrong port or the number of connections within a certian time reaches a threshhold, an alarm goes off. TCP_wrappers will also keep a record of any estblished connection which helps administrators find where an intruder came from. One problem which exists is that intruders can scan without establishing a connection. There is a technique for doing a half-open scan. The intruder can send a SYN packet that starts a connection, and if the port is active, it will respond with a SYN|ACK and the intruder records these packets, determining which ports were active now. In a typical established connection, the host responds to the SYN|ACK to finish completing the connection. The intruder can now send a reset packet removing from the kernel that a connection was half open. Here's the interesting information. ---- We do not even need to use a SYN packet to scan. Many firewalls block outside networks from sending in a SYN packet and that stops initiating a connection. So even the half-open scan won't work past a firewall. But we have tried other TCP flags and found many other packets will do the trick just as good, and if not better. Here's a table of the packets and response types to determine active ports. Flag Active Port Response Non-active Port Response SYN SYN|ACK Reset or Nothing SYN|FIN ACK or SYN|ACK* Reset ACK Nothing Reset 0 flag Nothing Reset * Depends on the TCP implementation. Windows 95 returned SYN|ACK while most Unix platforms return an ACK. We have picked the most interesting flags. You can also add URG and PUSH flags to any of the above flags and get the same response. The SYN|FIN is an illegal type of flags that contradict themselves, but a few router based firewalls that were blocking the other type packets allow this one through. The 0 flag packets are packets that designate the packet type as 0, which some packet filter based firewalls may allow through. Some firewalls allow ACK packets through as well. Using these type of packets, we called this a "stealth scan" because typically most TCP port scan detectors do not catch this type of activity and the scan enables you to bypass a firewall and see what services are running on the inside machines. Denial of Service Attacks ------------------------- In coming up with developing this code, we are able to do 2 types of denial of service attacks that people should be aware of and at some point, we need to have vendors fix the problems. 1) By scanning with all these different types of packets, we were able to crash a few popular type routers that could not handle these packets. We reported the problem back to the vendors. 2) By scanning with half-opens and not sending a RESET, the kernel's cache of half-open connections get full and will no longer accept any more connection. This would be a quick and easy way to cause a high connection rate machine to no longer provide any more connections, denying anyone from access to a machine, including a Web server. Solutions --------- Do not rely completely on SATAN detectors. Most of them are designed to only signal alarms if a full established connection is made. Courtney.pl is the only SATAN detector that we found that actually looked at the packets themselves looking for SYN packets. To detect a stealth scan, we need to come up with some heuristics for detecting an anomly of the number of reset packets generated as well. For denial of service attacks, if a device can't handle the packets it will be up to the vendor to provide a patch to fix this. Vendors need to look at potential solutions for half open attacks such as increasing in the kernel the number of half open connections possible, decreasing the time that the cached half opens stay in the memory, possibly logging when a particular host has filled up the half open cache and ignoring further half open packets from the offending host. Firewalls --------- The more secure setup of firewalls tend to be a combination of both packet filter / proxy server type firewalls that would prevent scanning past the firewall if configured properly. /--------------------------------------------------------------------------- -----------------\ To get on mailing list, Alert, send a message to alert-request@iss.net and within the message, type: subscribe alert \--------------------------------------------------------------------------- -----------------/ Copyright This paper is Copyright (c) 1994, 1995 by Christopher Klaus of Internet Security Systems, Inc. Permission is hereby granted to give away free copies electronically. You may distribute, transfer, or spread this paper electronically. You may not pretend that you wrote it. This copyright notice must be maintained in any copy made. If you wish to reprint the whole or any part of this paper in any other medium excluding electronic medium, please ask the author for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Address of Author Please send suggestions, updates, and comments to: Christopher Klaus of Internet Security Systems, Inc. Internet Security Systems, Inc. Internet Security Systems, Inc, located in Atlanta, Ga., specializes in the developement of security scanning software tools. Its flagship product, Internet Scanner, is software that learns an organization's network and probes every device on that network for security holes. It is the most comprehensive "attack simulator" available, checking for over 100 security vulnerabilities. -- Christopher William Klaus Voice: (770)441-2531. Fax: (770)441-2431 Internet Security Systems, Inc. "Internet Scanner lets you find 2000 Miller Court West, Norcross, GA 30071 your network security holes Web: http://iss.net/ Email: cklaus@iss.net before the hackers do." From firewalls-owner Mon Dec 4 00:26:14 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id AAA14783 for firewalls-outgoing; Mon, 4 Dec 1995 00:21:04 -0800 (PST) Received: from westie.gi.net (westie.gi.net [198.247.250.16]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id AAA14778 for ; Mon, 4 Dec 1995 00:21:01 -0800 (PST) Received: (from alan@localhost) by westie.gi.net (8.7.1/8.7.1) id CAA10335; Mon, 4 Dec 1995 02:21:31 -0600 (CST) From: Alan Hannan Message-Id: <199512040821.CAA10335@westie.gi.net> Subject: Re: Security of Leased Lines To: Alex.Eveleigh@kellogg.com (Alex Eveleigh) Date: Mon, 4 Dec 1995 02:21:30 -0600 (CST) Cc: firewalls@GreatCircle.COM In-Reply-To: <0bf2c6c0@cornelius.scp.com> from "Alex Eveleigh" at Dec 1, 95 11:13:55 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk This topic came up about 45 days ago. Check archives for my and 2 other fairly detailed analyses of the risks and issues involved. -alan ......... Alex Eveleigh is rumored to have said: ] ] I am interested in getting some feedback on how difficult it would be ] for someone to tap a leased line for a network connection and what ] possible defenses there are to reduce the risk of information ] transported on leased lines being monitored. ] ] Thanks in advance, ] ] Alex ] ] From firewalls-owner Mon Dec 4 01:38:28 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id AAA15457 for firewalls-outgoing; Mon, 4 Dec 1995 00:53:35 -0800 (PST) Received: from net4.sbic.co.za (net4.sbic.co.za [160.117.116.51]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id AAA15448 for ; Mon, 4 Dec 1995 00:53:10 -0800 (PST) From: Cameron_A_P@ceo.sbic.co.za Received: from zork.sbic.co.za by net4.sbic.co.za (5.x/SMI-SVR4) id AA01408; Mon, 4 Dec 1995 10:52:58 -0200 Received: by zork.sbic.co.za (1.00/net4) id AA00086; Mon, 4 Dec 95 10:50:06+2 Date: Mon, 4 Dec 95 10:50:06+2 Message-Id: <9512041550.AA00086@zork.sbic.co.za> To: firewalls@greatcircle.com Subject: Forwarded: Stealth Scanning - Bypassing Firewalls/SATAN Detectors X-Ceo_Options: Document Sender: firewalls-owner@GreatCircle.COM Precedence: bulk CEO comments: From: Cameron A P:SBIC Date: ## 12/04/95 10:49 ## Here is a document decsribing how a hacker can scan your site even if you have a Packet Filter Type Firewall. Previous comments: From: (Christopher Klaus) cklaus@iss.net:smtp Date: ## 12/04/95 10:17 ## See document for message. CEO document contents: To get on mailing list, Alert, send a message to alert-request@iss.net and within the message, type: subscribe alert Stealth Scanning - Bypassing Firewalls and SATAN Detectors ---------------------------------------------------------- Administrators need tools to find out what is going on in their network. Maybe an internal employee has installed a unauthorized web server and put proprietary information online allowing anyone to access it, how does an administrator find out that there is even a web server running on their network? Many administrators use tools called TCP Port scanners. These programs which try to connect to all possible ports on a machine find which services are running. This information gives a network administrator better ability to understand and be aware of how his or her network is configured. Unfortunately, this technology is a double-edge sword because intruders can scan other networks and be able to gather information that helps better mount an attack. The intruder now knows which machines are running and what services are available. TCP port scanning is built into shareware auditing tools, such as ISS (Internet Security Scanner) and SATAN. These tools were intended to help administrators correct security risks in their network, but unfortunately they are just as useful to the bad guys. Because TCP port scanning is like knocking on the door of many services, people have written tools like SATAN detectors which notify administrators when outside people are knocking on their network. This has made the administrator feel like they are getting a good alarm notice if a hacker decides to attack their network. Here is a problem that we want to educate people about and possibly come up with some better solutions to addressing this problem. Most of the TCP port scanning technology relies on making an established connection with a port to determine if it is active or not. Many of the SATAN/Port Scanning Detectors rely on this fact. They record the connections and if a connection happens to a wrong port or the number of connections within a certian time reaches a threshhold, an alarm goes off. TCP_wrappers will also keep a record of any estblished connection which helps administrators find where an intruder came from. One problem which exists is that intruders can scan without establishing a connection. There is a technique for doing a half-open scan. The intruder can send a SYN packet that starts a connection, and if the port is active, it will respond with a SYN|ACK and the intruder records these packets, determining which ports were active now. In a typical established connection, the host responds to the SYN|ACK to finish completing the connection. The intruder can now send a reset packet removing from the kernel that a connection was half open. Here's the interesting information. ---- We do not even need to use a SYN packet to scan. Many firewalls block outside networks from sending in a SYN packet and that stops initiating a connection. So even the half-open scan won't work past a firewall. But we have tried other TCP flags and found many other packets will do the trick just as good, and if not better. Here's a table of the packets and response types to determine active ports. Flag Active Port Response Non-active Port Response SYN SYN|ACK Reset or Nothing SYN|FIN ACK or SYN|ACK* Reset ACK Nothing Reset 0 flag Nothing Reset * Depends on the TCP implementation. Windows 95 returned SYN|ACK while most Unix platforms return an ACK. We have picked the most interesting flags. You can also add URG and PUSH flags to any of the above flags and get the same response. The SYN|FIN is an illegal type of flags that contradict themselves, but a few router based firewalls that were blocking the other type packets allow this one through. The 0 flag packets are packets that designate the packet type as 0, which some packet filter based firewalls may allow through. Some firewalls allow ACK packets through as well. Using these type of packets, we called this a "stealth scan" because typically most TCP port scan detectors do not catch this type of activity and the scan enables you to bypass a firewall and see what services are running on the inside machines. Denial of Service Attacks ------------------------- In coming up with developing this code, we are able to do 2 types of denial of service attacks that people should be aware of and at some point, we need to have vendors fix the problems. 1) By scanning with all these different types of packets, we were able to crash a few popular type routers that could not handle these packets. We reported the problem back to the vendors. 2) By scanning with half-opens and not sending a RESET, the kernel's cache of half-open connections get full and will no longer accept any more connection. This would be a quick and easy way to cause a high connection rate machine to no longer provide any more connections, denying anyone from access to a machine, including a Web server. Solutions --------- Do not rely completely on SATAN detectors. Most of them are designed to only signal alarms if a full established connection is made. Courtney.pl is the only SATAN detector that we found that actually looked at the packets themselves looking for SYN packets. To detect a stealth scan, we need to come up with some heuristics for detecting an anomly of the number of reset packets generated as well. For denial of service attacks, if a device can't handle the packets it will be up to the vendor to provide a patch to fix this. Vendors need to look at potential solutions for half open attacks such as increasing in the kernel the number of half open connections possible, decreasing the time that the cached half opens stay in the memory, possibly logging when a particular host has filled up the half open cache and ignoring further half open packets from the offending host. Firewalls --------- The more secure setup of firewalls tend to be a combination of both packet filter / proxy server type firewalls that would prevent scanning past the firewall if configured properly. ------------------------------------------------------------------------------ - Copyright This paper is Copyright (c) 1994, 1995 by Christopher Klaus of Internet Security Systems, Inc. Permission is hereby granted to give away free copies electronically. You may distribute, transfer, or spread this paper electronically. You may not pretend that you wrote it. This copyright notice must be maintained in any copy made. If you wish to reprint the whole or any part of this paper in any other medium excluding electronic medium, please ask the author for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Address of Author Please send suggestions, updates, and comments to: Christopher Klaus of Internet Security Systems, Inc. Internet Security Systems, Inc. Internet Security Systems, Inc, located in Atlanta, Ga., specializes in the developement of security scanning software tools. Its flagship product, Internet Scanner, is software that learns an organization's network and probes every device on that network for security holes. It is the most comprehensive "attack simulator" available, checking for over 100 security vulnerabilities. -- Christopher William Klaus Voice: (770)441-2531. Fax: (770)441-2431 Internet Security Systems, Inc. "Internet Scanner lets you find 2000 Miller Court West, Norcross, GA 30071 your network security holes Web: http://iss.net/ Email: cklaus@iss.net before the hackers do." From firewalls-owner Mon Dec 4 02:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA18794 for firewalls-outgoing; Mon, 4 Dec 1995 02:49:30 -0800 (PST) Received: from gate.ggr.co.uk ([193.128.25.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id CAA18789 for ; Mon, 4 Dec 1995 02:49:25 -0800 (PST) Received: from mailhub.ggr.co.uk (uk0x07.ggr.co.uk) by gate.ggr.co.uk; Mon, 4 Dec 1995 10:48:27 GMT Received: from ukwit01.ggr.co.uk (ukwit01.ggr.co.uk) by mailhub.ggr.co.uk; Mon, 4 Dec 1995 10:45:16 GMT Received: by ukwit01.ggr.co.uk (8.7.1/imd160294) id KAA04753; Mon, 4 Dec 1995 10:50:47 GMT From: "Lack Mr G M" Message-Id: <9512041050.ZM4751@ukwit01> Date: Mon, 4 Dec 1995 10:50:46 +0000 In-Reply-To: Anton J Aylward "Orange Book Irrelevant (was: A1 Systems?)" (Dec 3, 12:01pm) References: <199512031701.MAA09764@psyche.the-wire.com> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: firewalls@greatcircle.com Subject: Re: Orange Book Irrelevant (was: A1 Systems?) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > But that's not why the Orange Book is irrelvant to commercial comptuing in > the 1990's. Was it ever relevant? I could never understand why (some) people thought that a C2 system was a "good thing". To me it was more like having a CCTV system outside a warehouse. After the warehouse had burnt down you could see who had been around at the time, and hence (perhaps) apportion blame. But it didn't stop the warehouse burning down.... -- ----------- Gordon Lack ----------------- gml4410@ggr.co.uk ------------ The contents of this message *may* reflect my personal opinion. They are *not* intended to reflect those of my employer, or anyone else. From firewalls-owner Mon Dec 4 04:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id EAA21779 for firewalls-outgoing; Mon, 4 Dec 1995 04:41:25 -0800 (PST) Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk [137.44.100.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id EAA21774 for ; Mon, 4 Dec 1995 04:41:16 -0800 (PST) Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: Linux/freeBSD & Firewalls for a Newbw :-) (fwd) To: newton:communica.com.au@iiit.swan.ac.uk, firewalls@greatcircle.com Date: Mon, 4 Dec 1995 12:44:05 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > [ I know I'm going to get flamed for this, because Linux weenies are > even more virulent than Amiga weenies used to be, but I can't let > this pass. ] Grin. > > 4) How does Linux measure up against freebsd or bsdi ... I happen to love > > LINUX but faer it was designed with speed in mind and not security ... > Not quite -- It was designed with fun in mind, and the quantities of > speed and security that it offers are largely side effects. The Linux/FreeBSD firewalls are basically the same code. I wouldn't choose either for a high security environment. > above. The average Linux user is a UNIX newbie who sometimes even lacks > the skills necessary to tighten down a normal UNIX system, let alone a > firewall. Additionally, *cost* is usually the main factor which steers > someone into using Linux as a firewall ("Hey! We have a $75 386SX-25 > motherboard; we can put some cheap memory, cheap disk and a cheap > ethernet card on it and build ourselves a $500 firewall, instead of > buying two Ciscos and a bastion host! Q00l, eh?"). You miss something important here for all the cheap firewalling camps, if you only have $500 its better to at least be blocking out people spoofing local ip addresses remotely and very basic stuff than nothing. > The end result of this is a network which is "firewalled" (spit!) behind > a Linux box with some packet filters. By necessity, the Linux box runs > *actual net-accessible services* (heaven forbid!), which means that the > filters need gaps -- Hence, the machine is at risk of being compromised Not always. Those people who set it up right using an old 2Mb 386 a couple of network cards and no services exist. Very few people do this properly however. > The Linux scheduler and VM system is also pathetic enough to make you > not want to run services on the machine anyway, even though you essentially > have no choice. When a Linux machine runs a CPU- and IO-intensive Now this is why people get upset. You've just gone from some serious points on firewalling issues to rather irrelevant claims. For your benefit Linux 1.3.45 outperforms an equivalent BSD system on paging and context switching quite materially - lmbench rates the linux 1.3 schedule higher than any other comparable system. From a firewalling point of view thats not relevant anyway, as you said yourself you don't run services on a firewall. > expire run has finished. The only solutions to this problem are to > either rewrite the scheduler or install massive amounts of memory to Which was done a measurable number of months ago. > machine which does nothing but run sendmail, INN and a nameserver). On > just about any other operating system I can think of, 16Mb is more than > adequate for that role. Our servers are happy with INN in 16Mb, they are running more recent setups that 1.2. That also buys you almost double the IP forwarding performance and tree based routing with physical layer header caches. Good things for a router. > The bottom line is that Linux has not been designed as a firewall -- It Indeed. > has been designed as an OS that gets run on a single-user workstation > (NOT! a server, no matter how many glowing stories Linux advocates tell > you about its performance -- Linus Torvalds himself admits that the Sorry.. It works very nicely as a server too. > Linux kernel's scheduler does not perform well under load). As an OS Talking about the old 1.2 scheduler. > performance, and I would recommend it to anyone in that role. However, > it is not now, nor will it ever be, a firewall. Yes. > If you're using Linux as a firewall, you're more or less telling the > world that you simply don't give a damn about the first two of those > criteria. Again this depends. For low security firewalls that are just to keep annoying students out is great. I wouldn't suggest a high security site use anything that doesn't have a nice line of security certificates from competent authorities. There are BTW high security linux firewall packages like the Mazama one (www.mazama.com) but you pay for those. Linux now also supports loadable kernel firewall modules for those who want to write the worlds best firewall. Alan From firewalls-owner Mon Dec 4 05:24:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id EAA21997 for firewalls-outgoing; Mon, 4 Dec 1995 04:59:39 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id EAA21992 for ; Mon, 4 Dec 1995 04:59:33 -0800 (PST) Message-Id: <199512041259.EAA21992@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA105202027; Tue, 5 Dec 1995 00:00:27 +1100 From: Darren Reed Subject: port scanning. To: Firewalls@GreatCircle.COM (Firewalls Mailing List) Date: Tue, 5 Dec 1995 00:00:27 +1100 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk (hopefully this is far enough from being an actual exploit to be suitable for the firewalls list. Whilst not directly relevant to firewalls, I believe some of the details herein will be of interest to its readers). "Stealth Scanning": etcp Well since newscan is available, I don't see too much harm in making this tool available (I was unaware that it existed, previously). There are "bugs" here for everyone...:-(( Hassle your vendor if you find your machines susceptible to some of the stranger things below. This document describes the behaviour of etcp and thus explains to a fair extent how Stealth Scanning works, how to take advantage of buggy firewalls which don't send back replies and points out some bugs in TCP. etcp is the precursor to ipsend (which has diverged from the role of doing TCP port scans). It ONLY works over Ethernet. It's primary role was to exercise the short-TCP packet bug, but became a bit more flexible. It will ONLY run on SunOS4 (NIT or BPF) and 4BSD boxes with BPF. The command line looks something like this: etcp [-d device] [-f fragflags] [-g gateway] [-m mtu] [-p min] [-P max] [-s src] [-S source-port] [-t port] dest flags Device is obvious (which device you want the packet to go out from). (defaults to le0) The "fragflags" field is there to niggle another bug observed in packet filters (mainly setting the highest bit -ONLY- and sending a packet with this field as 0x8000, even though it wasn't a fragment). The gateway allows it to send packets through to another network. The mtu paramter. This did "most of the damage". The key value for this field is 28 - enough to put port numbers in one packet and TCP flags in the next. The min and max parameters specify the minimum and maximum ports for the scan. Default is 0 and 1023. Source allows for a different source address to be specified - almost useless unless you don't want to see the replies. Source port sets the given field in the TCP header. If the port number is given, with the -t option, it will try to make a TCP connection and then send data across without using in-kernel TCP. This option work best with an MTU of 28 against a packet screen'd firewall which doesn't return any ICMP/TCP packets in response to blocked packets. Why ? Because it relies on the screen remaining silent and not giving the kernel any cause to close the TCP connection. So, if that bug was available, it'd call connect(), expect the SYN packet to be dropped, send across a SYN split in two which would hopefully make it through, assume an answer, and then send across an ACK (using a system call) with actual data, doing a kernel lookup to get the sequence/ack numbers from the TCP PCB. Sometimes not sending a reply is more dangerous than sending one :-) Destination is the destination IP address. Flags is any combination of TCP flags (SAFRPU). This table shows the packets returned to those sent. The target machines were an Ultrix 4.3 box and a FreeBSD 2.0.5 box. Hopefully two different `poles' of BSD TCP. L - Listening, I - Inuse, U - unused S - SYN, A - ACK, F - FIN, R - RST All packets should be considered to have bad sequence/ack numbers. Sent State Received Window* S L SA !=0 S I - - S U RA 0 SA L RA/R# !=0 SA I A/- !=0/-# SA U R 0 F L A/- !=0/- F I - - F U RA/R 0 FA L R/- !=0/- FA I A/- !=0/- FA U RA 0 FS L RA/SA !=0 & FS I - - FS U RA 0 R L R/- !=0/- R I RA/- !=0/- + R U - - RA L RA/- !=0/- RA I RA !=0 + RA U - - * - on Solaris 2, RST packets always have a window of 0. + - On some Unixes, where a reply is shown as received, this can close the connection a la ICMP destination unreachable `nukes' - hassle vendor! # - FreeBSD 2.0.5 reponses, where different & - it appears that 4.4BSD treats FS as a S. When kernels based on BSD networking are targetted, a non-zero window is returned for sockets which are listening. This is due to them (a) having a non-zero window in the listening state and (b) a pointer, tp, being non-null when passed to tcp_close() to send the RST. In case (b), tp points to the listening socket. Looking at the above table, we can scan for active listening ports quite successfully, so long as we know what to expect back. In particular, using a SYN-ACK instead of a SYN seems particularly fruitful. It can be found at: ftp://coombs.anu.edu.au/pub/misc/etcp.tar.Z darren p.s. between this and ipsend, I've found `bugs' in TCP/IP on Solaris2.4, 4.4BSDs, Linux, SunOS4, Ultrix 4.3...so there are probably some in the others too! Some bugs are more benign than others, and at least two can be made to crash/panic and not reboot. From firewalls-owner Mon Dec 4 06:54:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA23752 for firewalls-outgoing; Mon, 4 Dec 1995 06:30:27 -0800 (PST) Received: from clouso.crim.ca (Clouso.CRIM.CA [192.26.210.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA23747 for ; Mon, 4 Dec 1995 06:30:23 -0800 (PST) From: PLAMONDON-A@immedia.ca Received: from immedia.ca (immedia.ca [192.139.197.1]) by clouso.crim.ca (8.6.11/8.6.11) with SMTP id JAA20166 for ; Mon, 4 Dec 1995 09:31:16 -0500 Received: by immedia.ca (4.10/2.D) id AA32569; 4 Dec 95 14:32:42 +0000 Date: 4 Dec 95 14:19:00 +0000 Message-Id: <199512041432.AA32569@immedia.ca> To: firewalls@greatcircle.com Subject: physical security Sender: firewalls-owner@GreatCircle.COM Precedence: bulk ---------- Bonjour, We are in process to upgrade our security (PHYSICAL) and I'm looking for STANDARDS on physical security for computer room, any informations are welcomes (pointer to other sources, experiences, standards etc). :-) Andre From firewalls-owner Mon Dec 4 07:29:55 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA23723 for firewalls-outgoing; Mon, 4 Dec 1995 06:27:30 -0800 (PST) Received: from gateway.damark.com (GATEWAY.DAMARK.COM [204.17.145.230]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA23712 for ; Mon, 4 Dec 1995 06:27:21 -0800 (PST) Received: by gateway.damark.com; id IAA07007; Mon, 4 Dec 1995 08:28:10 -0600 Received: from unknown(172.31.254.231) by gateway.damark.com via smap (g3.0.1) id sme007005; Mon, 4 Dec 95 08:28:02 -0600 Received: by damark.com (5.65/1.2-eef) id AA16625; Mon, 4 Dec 95 08:26:50 -0600 Message-Id: <9512041426.AA16625@damark.com> From: "william.wells" To: FIREWALLS Subject: FW: chroot/setuid vs type enforcement Date: Mon, 04 Dec 95 08:23:00 CST Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Leonard Miyata wrote: Once the Trusted Subject has been designed, implemented, and verified, the bulk of the rest of the Application is less of a problem. The unfortunate side-effect of this is that programming for a Trusted Security Kernal requires a greater level a programming skill then a conventional Box. --Having worked on systems where security was a very high concern for years, I personnel disagree that they take a greater level of skill. (That is, unless the security mechanisms aren't well integrated or one is trying to get around the security.) What security does require is attention. If someone comes from a "wide open" environment, then working in a security conscious environment will take some effort to learn but so does learning about chroot/setuid and other 'changes' made in firewalls. Being security conscious probably isn't a bad thing for any programmer. William Wells Manager, Technical Support Damark International, Inc From firewalls-owner Mon Dec 4 07:59:00 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA25109 for firewalls-outgoing; Mon, 4 Dec 1995 07:42:12 -0800 (PST) Received: from TIS.COM (neptune.tis.com [192.94.214.96]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA25103 for ; Mon, 4 Dec 1995 07:42:07 -0800 (PST) Received: from relay.tis.com by neptune.TIS.COM id aa02930; 4 Dec 95 10:38 EST Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.1) id xma012544; Mon, 4 Dec 95 10:12:44 -0500 Received: from sol.tis.com by tis.com (4.1/SUN-5.64) id AA24629; Mon, 4 Dec 95 10:38:01 EST Message-Id: <9512041538.AA24629@tis.com> To: mjr@iwi.com Cc: goertzek@gateway.wangfed.com, firewalls@greatcircle.com, lisaj@TIS.COM Subject: Re: A1 Systems? In-Reply-To: Your message of "Sat, 02 Dec 95 09:57:21 EST." <199512021457.JAA03362@switchblade.iwi.com> Date: Mon, 04 Dec 95 10:37:59 -0500 From: "Lisa M. Jaworski" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I can't help feel inflamed that people outside of TIS are making public statements about Marcus' work at TIS, as well as his attitudes in general. People will always talk but to cast aspersions that perhaps the reason why someone has an opinion is because they've been burned in the course of their employment is ludicrous. I worked with Marcus for the duration of his time at TIS and I feel honor-bound to say this. He's a wonderful person & he left TIS on VERY GOOD TERMS, both on a technical basis and a personal level with everyone who knew him. Anyone who thinks otherwise & would say so publicly is clearly wacko. Obviously, Marcus has already defended himself but as a TIS employee and someone who thinks very highly of Marcus' talents, opinions, & personality, I think this bears repeating. Lisa J. From firewalls-owner Mon Dec 4 08:32:04 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA24803 for firewalls-outgoing; Mon, 4 Dec 1995 07:21:17 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA24784 for ; Mon, 4 Dec 1995 07:21:07 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id JAA14859; Mon, 4 Dec 1995 09:24:41 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id JAA14855; Mon, 4 Dec 1995 09:24:37 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id JAA03798; Mon, 4 Dec 1995 09:22:30 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id JAA08753; Mon, 4 Dec 1995 09:22:30 -0600 From: Rick Smith Message-Id: <199512041522.JAA08753@shade.sctc.com> Subject: Re: A1 Systems? To: goertzek@wangfed.com Date: Mon, 4 Dec 1995 09:22:29 -0600 (CST) Cc: firewalls@greatcircle.com, smith@sctc.com In-Reply-To: <9512012041.AA01824@hfsi> from "K Goertzel" at Dec 1, 95 03:41:27 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Karen Goertzel has responded to my comments on SNS assurance. While this isn't a "today" issue in commercial firewalls, it illustrates an interesting question of "who do you trust" when looking at assurance evidence: > In message <199512011749.LAA18890@shade.sctc.com> Rick Smith writes: > > > Both LOCK and SNS have formal security policy models, top level > > specifications, formal proofs, covert channel analyses, the whole A1 > > nine yards. The only difference is that we've reorganized the > > development process to try to build high assurance products in real > > time. In other words, build something that doesn't combine high > > assurance with obsolescence. >Which means I, as a potential customer, am still stuck with the >problem of having to trust the car salesman's word that the car will >run. Point #1: the assurance evidence is reviewed by the same teams that review evidence for NCSC evaluations. If LOCK and SNS evidence is tainted, then all evidence is tainted. > Of course, I may also question the competence of NCSC's >evaluators, but at least they have no vested interest in a product >passing or failing evaluation (well, except in one case that shall >remain nameless where they have invested something like $20M in the >product's development; it's probably a good thing that that product >isn't going to go through a TCSEC evaluation, given the result would >be highly suspect given NSA's interest in seeing it pass). Point #2: the evaluators not the decisionmakers regarding the use of the system, they simply evaluate the evidence and make statements regarding its completeness and correctness. They are are contracted by NCSC but not directly employed by them. It's up to the government agencies involved to decide whether to field the thing. The high assurance evidence is an artifact in and of itself, produced and validated by independent teams. It provides a base of evidence for making the deployment decision. The benefit is that you have a clearer picture of risks than you do otherwise. That's the bottom line. Any other point of view gives us a process of "waving a dead chicken" like Marcus likes to say. There's no magical concept of absolute security imparted by a "B3" or even an "A1" rating. Just better evidence for assessing residual risks. Rick. smith@sctc.com secure computing corporation From firewalls-owner Mon Dec 4 09:24:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA26999 for firewalls-outgoing; Mon, 4 Dec 1995 08:42:37 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA26994 for ; Mon, 4 Dec 1995 08:42:30 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id LAA21977 for ; Mon, 4 Dec 1995 11:42:54 -0500 Date: Mon, 4 Dec 1995 11:42:54 -0500 Message-Id: <199512041642.LAA21977@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@GreatCircle.COM From: Anton J Aylward Subject: Small Demo scanner required. Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I'm looking for a small, possibly MS-windows based, scanner. Its intended to be used as a diversion from Powerpoint during presentations, as in: Who Hear has a Workstation on his deks? You! OK, lets see how vulnerable you are. It doesn't have to be up there with ISS, but if it could demo, for example, the telnetd problems that would be great! A simple report, something to impress the only slightly (wannbe) technical managers would be nice. Any pointers? /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Mon Dec 4 09:24:31 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA26436 for firewalls-outgoing; Mon, 4 Dec 1995 08:25:49 -0800 (PST) Received: from dns.eng.auburn.edu (dns.eng.auburn.edu [131.204.10.13]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA26420 for ; Mon, 4 Dec 1995 08:25:42 -0800 (PST) Received: from netman.eng.auburn.edu (netman.eng.auburn.edu [131.204.12.24]) by dns.eng.auburn.edu (8.6.12/8.6.4) with ESMTP id KAA25648; Mon, 4 Dec 1995 10:25:44 -0600 From: Doug Hughes Received: from localhost (doug@localhost) by netman.eng.auburn.edu (8.6.4/8.6.4) id KAA24510; Mon, 4 Dec 1995 10:25:40 -0600 Date: Mon, 4 Dec 1995 10:25:40 -0600 Message-Id: <199512041625.KAA24510@netman.eng.auburn.edu> To: academic-firewalls@net.tamu.edu, coast@cs.purdue.edu, firewalls@greatcircle.com, ids@uow.edu.au Subject: New version of tklogger available Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I've done some alterations/improvements on tklogger. - Improved support for regular expression matching and options for regular expression/exact math and case [in]sensitive matching But the major difference: - removed need for TclX This means it should be much more portable to mac/windows/NT type platforms. The only differences that may need to be made would be in the area of home directories, since by default it looks in your home directory for the config file. I'm not sure how to go about rectifying this for those platforms, since they treat this concept a little differently in each case. If anybody has some portable ideas on this, I'd be happy to integrate them. ----- What is tklogger? ------ It's a program that monitors log files in near-realtime on a user-defined polling interval. It has two windows, one for low priority and one for high priority items. High priority items are displayed in any color matching *red* and immediately deiconize and raise the logger window to the front of the display. Low priority items can be any color that does not have red in it, or just plain black. At its simplest, tklogger watches log files generated by syslog. But, the log files can be generated in any fashion that you wish, or that your firewall or other system might desire. tklogger just watches the logs and displays results. Tips: If you use syslog, forward your logs to a central, secure, restricted access machine. This way, even if somebody does a flood type attack on syslog, you're sure to notice it. Don't set the polling interval below 5 seconds, particularly if you are watching lots of different files. Don't use too many regular expressions for pattern matching, the results may slow down the application considerably (unless you have very little information being logged) You can either have lots of files, or lots of regular expressions, but try not to mix both. I have not stress tested it, but at a polling interval of ten seconds, it should easily handle 30-60 messages. Log what you think is important to the priority window. If you try to log too much stuff, you are likely to get very annoyed at the window constantly popping to the front. It works best if you log the information that is important to you, and have other people logging information important to them. Logging too much information will annoy you, and make you less likely to notice the really important stuff. This works extremely well with tcp_wrappers, klaxon, courtney, and other intrusion detection/port monitoring/log generating applications. here's a sample configuration file and some comments: - file operations specify a valid file name and a handle for the file to use internally to the program - color operations are used to associate colors with file handles (not all handles have to have colors, but a color must have a handle) - match operations use regular expressions to look for specific keywords and highlight those differently and prioritized above the generic 'color' operation - ignore operations can be used like match operations file auth /var/log/authlog file daemon /var/log/daemon file local0 /var/log/local0.info file local1 /var/log/local1.note file local2 /var/log/local2.warn file local3 /var/log/local3.note file maillog /var/log/maillog color local0 forestgreen color local1 lightseagreen color local2 magenta color local3 red1 color auth red2 match {LOGIN FAILURE} mediumvioletred match (pgcntd|refused) red4 match portwatcher red3 match (vrfy|expn) violetred ignore xntpd -- What do I need? you need a working copy of wish (Tcl/Tk executable) Source code for unix, and binaries for mac/windows/NT are available at: ftp.sunlabs.com:pub/tcl There is also a collection of Web pages on Tcl and Tk at the URL http://www.sunlabs.com/research/tcl. -- Where do I get tklogger? ftp.eng.auburn.edu:pub/doug/tklogger ftp.eng.auburn.edu:pub/doug/tklogger.asc (ASCII PGP signed version) ftp.eng.auburn.edu:pub/doug/tklogger.pgp (Binary PGP signed version) http://www.eng.auburn.edu/users/doug/second.html (includes configuration guidelines mentioned above) There is also a mirror on coast, but that version is currently not up to date (though it should be soon). Doug Hughes Engineering Network Services doug@eng.auburn.edu Auburn University From firewalls-owner Mon Dec 4 09:54:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA29070 for firewalls-outgoing; Mon, 4 Dec 1995 09:38:27 -0800 (PST) Received: from bagout.bell-atl.com (bagout.Bell-Atl.Com [192.204.96.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA29044 for ; Mon, 4 Dec 1995 09:38:13 -0800 (PST) Received: by bagate.BELL-ATL.COM (O) id ; Mon, 4 Dec 95 12:39 EST Received: by bagate.BELL-ATL.COM (I1) id ; Fri, 1 Dec 95 07:50 EST Received: by is000913.BELL-ATL.COM (4.1/SMI-4.1) id AA03850; Fri, 1 Dec 95 07:50:40 EST From: bncqraq@is000913.BELL-ATL.COM (Morris) Message-Id: <9512011250.AA03850@is000913.BELL-ATL.COM> Subject: tn3270 proxy summary To: firewalls@GreatCircle.COM Date: Fri, 1 Dec 1995 07:50:39 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk It would seem that tn3270 is just telnet and that a telnet proxy such as the TIS telnet proxy will work just fine. Many thanks to all that responded to query. Joe -- =%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%= Joe W. Morris Specialist, Bell Atlantic E-mail: joe@bell-atl.com Phone: 301-236-7698 FAX: 301-236-8021 13101 Columbia Pike, Room 209B Silver Spring, MD 20904 =%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%=-=%@%= #include Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke From firewalls-owner Mon Dec 4 10:04:57 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA28179 for firewalls-outgoing; Mon, 4 Dec 1995 09:12:37 -0800 (PST) Received: from ncar.UCAR.EDU (ncar.ucar.edu [192.52.106.6]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id JAA28174 for ; Mon, 4 Dec 1995 09:12:31 -0800 (PST) Message-Id: <199512041713.KAA21334@ncar.ucar.EDU> Received: by ncar.ucar.EDU (NCAR Local/ NCAR Central Post Office 03/11/93) id KAA21334; Mon, 4 Dec 1995 10:13:20 -0700 (MST) Subject: Re: SDI's Time-Synched SecurIDs To: firewalls@greatcircle.com Date: Mon, 4 Dec 95 10:13:20 MST In-Reply-To: ; from "Vin McLellan" at Dec 2, 95 11:21 pm From: woods@ncar.ucar.edu (Greg Woods) X-Mailer: ELM [version 2.3 PL11] Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > Padgett: Any idea what sort of logic went into MMC's purchase of > the 3-year SecurID, rather than the cheaper 4-year SecurID? I can't speak for Padgett, but here, one reason was that we did not want to be locked into one vendor (SDI) for the longer time period. We do not all share Vin's apparent unquestioning loyalty to Security Dynamics. Personally I have found them very difficult to deal with; it took two weeks of haggling between our legal department and theirs to get an acceptable demo agreement, for instance (the default agreement required *us* to pay shipping to demo *their* product, as an example of the things our contracts people found objectionable). Their response to us pointing out that the ACE server flat out doesn't work with dual-homed clients was to say that we had to change the way we resolve addresses and names for our dual-homed hosts; they would not admit that it's simply broken (since our setup for the dual-homed hosts is not at all unusual). I could only get our dual-homed clients to work by running it through the TIS authentication server first (using "login-sh" instead of "sdshell" as the users' shell and letting the TIS authentication server deal with the ACE server). It certainly appeared to me after all this that SDI is not very responsive to customer problems. There was a lot of the "we're the phone company, we don't care, we don't have to" attitude there, and I certainly did not want to be locked in to that vendor for any longer than necessary (as it happens, we needed SDI because at present they are the only product that will work with TACACS on Cisco routers since the current version of TACACS won't support challenge/response; I understand Cisco is planning to support TACACS+ with C/R; I can't wait). At least one other vendor, for instance, was willing to ship me their products to demo based on a simple agreement that I would return them at the end of the demo period. Plus, I suspect the up-front cost is often an issue. The four-year cards are cheaper than the three-year cards PER YEAR, but they cost more up front. --Greg From firewalls-owner Mon Dec 4 10:24:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA29389 for firewalls-outgoing; Mon, 4 Dec 1995 09:49:15 -0800 (PST) Received: from Disclosure.COM (di2.disclosure.com [205.156.194.11]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA29374 for ; Mon, 4 Dec 1995 09:49:09 -0800 (PST) Received: by Disclosure.COM (4.1/SMI-4.1) id AA21041; Mon, 4 Dec 95 12:53:25 EST Date: Mon, 4 Dec 1995 12:53:24 -0500 (EST) From: Scott Barman To: PLAMONDON-A@immedia.ca Cc: firewalls@greatcircle.com Subject: Re: physical security In-Reply-To: <199512041432.AA32569@immedia.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On 4 Dec 1995 PLAMONDON-A@immedia.ca wrote: > Bonjour, > > > We are in process to upgrade our security (PHYSICAL) and I'm looking for > STANDARDS on physical security for computer room, any informations are > welcomes (pointer to other sources, experiences, standards etc). > > :-) Andre This reminds me of a (sort of) funny story, which has a lesson in it: When I was consulting at Bellcore, I came across the old computer room--which was turned into a junk pile. I asked why was all this open space being wasted when (at that time) the existing computer room was cramped and the operation people practically begging for more space. I was escorted to the otherside of the room where I saw a broken window. It seemed that right before the actual breakup of Ma Bell, an AT&T employee was so upset with having been assigned to Bellcore this person tried to break the window to get into the computer room to vandalize it. At the time, it seemed that AT&T was more trusting of its employees than Bellcore. According to my guide, shortly after the incident (and breakup of the phone company), Bellcore management locked the machines up in rooms with no windows and heavy (non-wood) doors requiring access cards "guarding" the entrances. All the old computer rooms, which all had windows, were turned into graveyards for old computer equipment. This was the mid-80s, so I hope Bellcore has found a better use for this space!! :-) You need to determine how important physical security is to you and your company. For example, if you're going to lock the machines up in a single room with access control and monitoring, you don't put in a door with a glass window! It's a simple thing that is often overlooked! I cannot tell you how many government agencies I've visted that claim to have secure systems and look at me with surprise when I ask for a hammer. Only one challenged me on that because they were using bullet-proof/break-proof glass. :-) scott barman -- scott barman DISCLAIMER: I speak to anyone who will listen, scott@disclosure.com and I speak only for myself. barman@ix.netcom.com "I don't know if security explains why the Win95 support Web servers run BSDI 2.0--an Intel-based Unix--rather than Windows NT, which Microsoft insists is the ideal Web software solution. Does Redmond know something we don't know?" -Robert X. Cringely, INFORWORLD, 9/11/95 From firewalls-owner Mon Dec 4 11:24:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA03393 for firewalls-outgoing; Mon, 4 Dec 1995 11:12:50 -0800 (PST) Received: from uu7.psi.com (uu7.psi.com [38.8.39.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA03387 for ; Mon, 4 Dec 1995 11:12:43 -0800 (PST) From: joe.reeves@imail.exim.gov Received: from imail.exim.gov by uu7.psi.com (5.65b/4.0.940727-PSI/PSINet) via SMTP; id AA16083 for firewalls@greatcircle.com; Mon, 4 Dec 95 14:13:27 -0500 Received: from ccMail by imail.exim.gov (SMTPLINK V2.10.08) id AA818115253; Mon, 04 Dec 95 14:12:12 EST Date: Mon, 04 Dec 95 14:12:12 EST Message-Id: <9511048181.AA818115253@imail.exim.gov> To: firewalls@greatcircle.com Subject: Netra and Firewall-1 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Any ideas on getting FireWall-1 v1.2.1 configured on a Netra Server. We have had all kinds of problems. Apparently, the Solaris OS is scaled-down and alot of the commands on a regular Sparc 20 arent there. I think the manual was written assuming your on a Sparc. Any inside hints on installation. Thanks From firewalls-owner Mon Dec 4 11:54:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA04498 for firewalls-outgoing; Mon, 4 Dec 1995 11:45:06 -0800 (PST) Received: from svcs1.digex.net (svcs1.digex.net [204.91.197.224]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA04492 for ; Mon, 4 Dec 1995 11:45:02 -0800 (PST) Received: from GWFX1.sysorex.com (gwfx1.sysorex.com [204.192.18.20]) by svcs1.digex.net (8.6.12/8.6.12) with SMTP id OAA11113 for ; Mon, 4 Dec 1995 14:45:51 -0500 Received: from ccMail by GWFX1.sysorex.com (SMTPLINK V2.10.08) id AA818117159; Mon, 04 Dec 95 14:42:51 EST Date: Mon, 04 Dec 95 14:42:51 EST From: "Dave Druitt" Message-Id: <9511048181.AA818117159@GWFX1.sysorex.com> To: firewalls@greatcircle.com Subject: Re: Field of dreams Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >What a great idea! >A real set of security definitions based on real-world scenarios! >This HAS to be a first... We tried (firewalls-standards). Few came & it went downhill from there. Warmly, Padgett __________________________________ Maybe you were ahead of your time, and that time has come now. Is there anything to lose? We are already here... Should we vote? Dave Druitt Sr. Systems Engineer and Token UNIX specialist Sysorex Information Systems From firewalls-owner Mon Dec 4 12:10:52 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA02703 for firewalls-outgoing; Mon, 4 Dec 1995 10:57:04 -0800 (PST) Received: from eci-esyst.com (199-186.ico.att.net [199.186.17.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA02687 for ; Mon, 4 Dec 1995 10:56:55 -0800 (PST) Received: by eci-esyst.com (4.1/SMI-4.1) id AA02956; Mon, 4 Dec 95 13:53:57 EST Received: from rodney.eci-esyst.com(199.186.17.5) by callisto.eci-esyst.com via smap (V1.3mjr) id sma002951; Mon Dec 4 13:53:51 1995 Received: from jle9 ([191.254.66.132]) by callisto (4.1/SMI-4.1) id AA18513; Mon, 4 Dec 95 13:55:20 EST Message-Id: <9512041855.AA18513@callisto> Date: Mon, 04 Dec 95 13:57:35 -0800 From: "Jerry L. Edmiston" Organization: ECI div of E-SYSTEMS X-Mailer: Mozilla 1.22 (Windows; U; 16bit) Mime-Version: 1.0 To: firewalls@greatcircle.com Subject: (no subject) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I am running smap and smapd on the firewall. Mail comes in with one of two types of addesses, userid@domain.com or userid@host.domain.com. Mail comes into the firewall and is passed to the mailhost if a host name is not specified. Sendmail.cf re-writes the address, via the alaises file, and deliveres to the host. If a host is specified, an attempt is made to foward the mail to that host from the firewall server. This is fine unless that particular host is 'down'. In this case, the mail seems to be getting into a loop within smap and smapd on the firewall. If the mailhost (which only runs sendmail, not smap and smapd) attempts to deliver the mail to the 'downed' host, sendmail reconizes this and places the mail in the 'mqueue' file which is what it should do. Our theroy is that sendmail gives the mail back to smap, which stuffs it in his directory for smapd, smapd retrieves the message and gives it to sendmail and the loop continues until 30 hops occurre, 1 per minute, and the message is bounced back to the sender. Are we on the right track and if we are is there anyway to tell smap/smapd that the host is not reachable and to store the message until a later time, such as what sendmail does with un-deliverable mail and the mqueue file...please help...jle9@eci-esyst.com From firewalls-owner Mon Dec 4 12:27:37 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA05749 for firewalls-outgoing; Mon, 4 Dec 1995 12:17:50 -0800 (PST) Received: from access.netaxs.com (access.netaxs.com [198.69.186.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA05744 for ; Mon, 4 Dec 1995 12:17:46 -0800 (PST) Received: from unix5.netaxs.com (unix5.netaxs.com [198.69.186.7]) by access.netaxs.com (8.6.12/8.6.11) with ESMTP id PAA05887 for ; Mon, 4 Dec 1995 15:18:39 -0500 Received: (morph_1@localhost) by unix5.netaxs.com (8.6.11/8.6.9) id PAA20368; Mon, 4 Dec 1995 15:18:36 -0500 Date: Mon, 4 Dec 1995 15:18:35 -0500 (EST) From: Morph cc: firewalls@GreatCircle.COM Subject: Re: Small Demo scanner required. In-Reply-To: <199512041642.LAA21977@psyche.the-wire.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Mon, 4 Dec 1995, Anton J Aylward wrote: > I'm looking for a small, possibly MS-windows based, scanner. > Its intended to be used as a diversion from Powerpoint > during presentations, as in: > > Who Hear has a Workstation on his deks? > You! OK, lets see how vulnerable you are. > > It doesn't have to be up there with ISS, but if it could > demo, for example, the telnetd problems that would be great! > A simple report, something to impress the only slightly > (wannbe) technical managers would be nice. > How the hell do people like you get jobs? Not to be insulting or anything. if you think i was insulting i will sue. -- ---------------------------------------------------------------------------- Morph (morph_1@nextas.com) Morph's Elite Research Labs, Inc. From firewalls-owner Mon Dec 4 13:54:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA08120 for firewalls-outgoing; Mon, 4 Dec 1995 13:19:02 -0800 (PST) Received: from CyberSecure.Com (port1120.pubnix.net [199.84.157.120]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA08097 for ; Mon, 4 Dec 1995 13:18:26 -0800 (PST) Received: from patrick (Gaston.CyberSecure.Com [205.237.227.4]) by CyberSecure.Com (8.6.11/8.6.9) with SMTP id QAA01426 for ; Mon, 4 Dec 1995 16:18:21 -0500 Message-Id: <199512042118.QAA01426@CyberSecure.Com> X-Sender: pdrolet@cybersecure.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Dec 1995 16:18:05 -0500 To: firewalls@greatcircle.com From: Patrick Drolet Subject: Filtering fragmented IP frames Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Filtering IP frames is quite simple. Filtering UDP/IP or TCP/IP frames seems quite simple... The problem filtering TCP/IP is fragmentation; How does a firewall (or even a Cisco Secure Router) manage to filter fragmented IP frames knowing that the TCP or UDP header is only on the first frame ? Patrick. .-------------. | CyberSecure | |-----------------------------------------------------------. | Patrick Drolet, eng. | | | pdrolet@cybesecure.com | Can your network keep a secret ? | | (514) 289-8520 | | `-----------------------------------------------------------' From firewalls-owner Mon Dec 4 14:03:29 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA05635 for firewalls-outgoing; Mon, 4 Dec 1995 12:15:13 -0800 (PST) Received: from access.netaxs.com (access.netaxs.com [198.69.186.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA05630 for ; Mon, 4 Dec 1995 12:15:09 -0800 (PST) Received: from unix5.netaxs.com (unix5.netaxs.com [198.69.186.7]) by access.netaxs.com (8.6.12/8.6.11) with ESMTP id PAA05673; Mon, 4 Dec 1995 15:15:56 -0500 Received: (morph_1@localhost) by unix5.netaxs.com (8.6.11/8.6.9) id PAA20221; Mon, 4 Dec 1995 15:15:52 -0500 Date: Mon, 4 Dec 1995 15:15:50 -0500 (EST) From: Morph To: "Lisa M. Jaworski" cc: firewalls@GreatCircle.COM Subject: Re: A1 Systems? In-Reply-To: <9512041538.AA24629@tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Mon, 4 Dec 1995, Lisa M. Jaworski wrote: > I can't help feel inflamed that people outside of TIS are making > been burned in the course of their employment is ludicrous. I worked > with Marcus for the duration of his time at TIS and I feel honor-bound > VERY GOOD TERMS, both on a technical basis and a personal level with > everyone who knew him. Anyone who thinks otherwise & would say so publicly > is clearly wacko. Obviously, Marcus has already defended himself but as a > opinions, & personality, I think this bears repeating. > > Lisa J. > haw haw, he get's women to stick up for him. what a pathetic moron. sheesh. and i ain't no wacko. if u call me a wacko i will sue. -- ---------------------------------------------------------------------------- Morph (morph_1@nextas.com) Morph's Elite Research Labs, Inc. From firewalls-owner Mon Dec 4 14:24:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA06848 for firewalls-outgoing; Mon, 4 Dec 1995 12:43:18 -0800 (PST) Received: from utrecht.knoware.nl (utrecht.knoware.nl [193.78.120.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA06843 for ; Mon, 4 Dec 1995 12:43:11 -0800 (PST) Received: from csehost.idiscover.co.uk (csehost.idiscover.co.uk [194.128.134.177]) by utrecht.knoware.nl (8.6.12/8.6.12) with SMTP id VAA10479; Mon, 4 Dec 1995 21:43:44 +0100 Date: Mon, 4 Dec 1995 21:43:44 +0100 Message-Id: <199512042043.VAA10479@utrecht.knoware.nl> X-Sender: njb@pop.knoware.nl Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@greatcircle.com From: njb@knoware.nl (Niels Bjergstrom) Subject: Re: physical security Cc: PLAMONDON-A@immedia.ca X-Mailer: Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > Bonjour, > > > We are in process to upgrade our security (PHYSICAL) and I'm looking for > STANDARDS on physical security for computer room, any informations are > welcomes (pointer to other sources, experiences, standards etc). > > :-) Andre Bonjour, chere collegue, Tout ca est vraiment tres simple: Il faut construire une chambre avec the firewalls dans tout les cotees (et, peut etre, aussi aux coins), et faire *very* sure que tout les portes sont des porte aux firewalls! (A qui, qu'a les feux a l'interieur il ne manque jamis a bruler, et cela, c'est tres comfortable a l'hiver). Et surtout - pas des fenetres (le feu pouvait eschapper!!). Pas une probleme, vraiment :-) Niels PS: My apologies to those who do not appreciate jokes. Standards do indeed exist, though possibly not ANSI ones. There are DIN standards, but they are a bit aged. Anyway, an interior window-less brick room with one (armoured) door, a second-hand submachine gun (no ammo needed), a small lightshow and a good WAW-player should do the job in all but te most severe cases. From firewalls-owner Mon Dec 4 15:02:41 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA11674 for firewalls-outgoing; Mon, 4 Dec 1995 14:44:22 -0800 (PST) Received: from montag33.residence.gatech.edu (montag33.residence.gatech.edu [199.77.171.12]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA11668 for ; Mon, 4 Dec 1995 14:44:18 -0800 (PST) Received: (from brain21@localhost) by montag33.residence.gatech.edu (8.6.12/8.6.9) id RAA02817; Mon, 4 Dec 1995 17:44:31 -0500 Date: Mon, 4 Dec 1995 17:44:31 -0500 (EST) From: Brain21 To: firewalls@GreatCircle.COM Subject: Re: is a second filter router worthwhile? In-Reply-To: <199512011416.IAA26863@galil.austnsc.tandem.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Fri, 1 Dec 1995, Sten Drescher wrote: > Well, the SOCKS ftp client uses (I think) the PASV command to > tell the ftp server to use passive TCP ports for transfers. That is, > rather than the ftp server creating the connection to the client, it > opens a port, tells the client what port to connect to, and waits for > the client to create the connection. This way, the connection is > originating inside the SOCKS firewall, instead of outside it. > There are ftp clients/servers who do not understand the PASV command. Anyone know how prevalent these are, and if this is something to be worried about? IOW, should I set up an ftp that issues the PASV command, or should I use something like relay and have it sent to other ports, and what problems would this cause? Obviously the incoming ftp call would have to come to the gateway or firewall running relay. What are the configuration issues w/ this? Thanks, Brain21 From firewalls-owner Mon Dec 4 15:18:24 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA04959 for firewalls-outgoing; Mon, 4 Dec 1995 11:59:28 -0800 (PST) Received: from foxtrot.worldcom.com (foxtrot.worldcom.com [198.64.193.12]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id LAA04954 for ; Mon, 4 Dec 1995 11:59:21 -0800 (PST) Received: (from smtp@localhost) by foxtrot.worldcom.com (8.7.1/8.6.9) id NAA29517 for ; Mon, 4 Dec 1995 13:45:28 -0600 (CST) Received: from samba.worldcom.com(198.64.193.32) by foxtrot.worldcom.com via smap (V1.3) id sma029196; Mon Dec 4 13:43:23 1995 Received: (smtp@localhost) by samba.worldcom.com (8.6.11/8.6.9) id NAA21744 for ; Mon, 4 Dec 1995 13:43:22 -0600 Received: from samba.worldcom.com(198.64.193.32) by samba.worldcom.com via smap (V1.3) id sma021741; Mon Dec 4 13:43:18 1995 Date: Mon, 4 Dec 1995 13:43:18 -0600 (CST) From: Robert Dana Reply-To: Robert Dana Subject: Type enforcement vs chroot and buffers To: firewalls@greatcircle.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I want to be sure I understand this- please correct me if my summary of the issues is incorrect. If a process is executing code from a program that is badly written, there are several different techniques that fall under the umbrella description "buffer overflow attack" that may enable an unauthorized user to cause their own code to be executed in that process instead of the intended original program. Chrooting and type enforcement (as implemented by SCTC) are two techniques for addressing the problem of needing to protect your system against processes running possibly hostile code. Chroot goes a long way towards restricting access to dangerous parts of the system in a very simple and drastic way. Chroot itself isn't vulnerable to buffer overruns, but because it's not comprehensive, there are other, unprotected kernel interfaces that a hostile program can exploit to open security holes. MJR and SCTC both agree that these other points of vulnerability in the kernel interface should be identified and blocked. MJR advocates making simple, ad hoc modifications to the kernel, such as preventing chrooted processes from using socket(). This is often what firewall vendors who claim to have "hardened" kernels do. SCTC's type enforcement is a formalized but complex (in comparison) mechanism for accomplishing the same thing. Type enforcement creates abstraction and more flexibility in configuring the access controls, but introduces a lot more security-critical code to verify. Have I got it straight? -Robert -- Robert Dana (713) 650-6522 x240 WorldCom Director of Network Services Wolf Communications, Houston, TX Go WorldCom! From firewalls-owner Mon Dec 4 15:24:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA11591 for firewalls-outgoing; Mon, 4 Dec 1995 14:41:09 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA11577 for ; Mon, 4 Dec 1995 14:41:01 -0800 (PST) Received: from splinter.rtp.dg.com by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA27985; Mon, 4 Dec 1995 17:41:43 -0500 Received: by splinter (8.6.10/rtp-s04) id WAA11097; Mon, 4 Dec 1995 22:40:33 GMT From: spencerj@dg-rtp.dg.com (Jon Spencer) Message-Id: <199512042240.WAA11097@splinter> Subject: Re: A1 Systems? To: goertzek@wangfed.com Date: Mon, 4 Dec 95 17:40:28 EST Cc: firewalls@GreatCircle.COM In-Reply-To: <9511302245.AA25981@hfsi>; from "K Goertzel" at Nov 30, 95 5:45 pm X-Mailer: ELM [version 2.3 PL11] Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I guess maybe my last mail did not get out, but again I must comment on those messages from people who do not understand the evaluation process, its purpose, or its perversion. This writer is supportive of evaluated systems, and I do not mean to pick on him - or anyone. I just want to try to help set the record a bit straighter. > > In message <199511301953.AA03140@pnh10.med.navy.mil> writes: > > > > The main point I see is that high security and assurance of that > > security (2 different animal) has high overhead (system and > > administrative). Many of us (at least I) would be happy to have a > > high assurance C-2 file server Wellllll - then you really want an ITSEC certified E4/F-C2 system. But this doesn't do much for you, since C2 does very little for you. > > This is a contradiction in terms -- at least in accepted TCSEC terms. "High > assurance" refers to systems at the Class B2 level and above. What makes the > system "high assurance" is the fact that a covert channel analysis has been > performed which, essentially, assures that software functions cannot illicitly > share data, and thus cannot create "backdoors" which can be exploited for > violating the system's mandatory access control policy. That is NOT what high assurance is - covert channel searches do not occur until B2 because you must have the basis of HA to do them! Not the other way around. HA simply means that you have done high quality software engineering - your design matches your code, your tests match your design and claims, your documentation actually documents the real system, and you have a good proven model to base things on. Some may say that commercial systems can't be B2. They are really saying that commercial systems don;t really have to work. I can say this as the architect of a full commercial system in eval at B2 (and at E4 in the UK). "Full commercial" menas threads, SMP, NUMA, networking, transparency, firewall, guard, etc. etc., running off the shelf apps. Without HA, how do you *KNOW* that your firewall even works? Does anyone actually claim that they can test in quality? And do they even try to? > > > and a relativly "snoop-free" net. A-1 > > has a very limited customer base and an even lower interest base > > (IMNSHO). > > I will agree with the "very limited customer base". I am not sure I agree with > the "even lower interest base". I think if the A1 systems were there, you would > find customers in multi-level data environments who are finally beginning to > demand them. As it is, they are settling for B3 systems, B2 systems, and B1 > systems -- and assuming a much higher level of risk than would be necessary if > there were any useful A1 systems on the market. > > Indeed, I don't think you're ever going to see high-assurance "general purpose" > computers competing with Sun SparcCenters or IBM mainframes. What you are going > to see, however, is a proliferation of trusted guard applications that will > enable users to connect networks that were never before able to interconnect due > to classification restrictions. And these are not just Defence customers -- our > most avid MLS customers are in the FBI, the IRS, and the State Department. Funny - we have a general purpose computer (Intel and Motorola based, with industry leading TPC numbers, etc.) that is high assurance. Never say never (or, rather "I don't think you're ever".) > > I also deal frequently with the security/accreditation officers for numerous > U.S. and foreign government agencies, and in many cases their policy is that > they will not accept systems that have not been evaluated. They simply are > unwilling to assume the risk implied by trusting the vendor's word alone that > the alleged security mechanisms on his system work exactly as documented, with > no backdoors or other vulnerabilities. The TCSEC/ITSEC approach to assuring > system security may be flawed, but I think it's better than trusting the INFOSEC > equivalent of a used car salesman, don't you? > > > > Karen Goertzel > Manager, International Programmes and Special Projects > Secure Systems and Services Operation > Wang Federal, Inc. > 7900 Westpark Drive - MS 700 > McLean, Virginia 22102-4299 > TEL: 703-827 3914 > FAX: 703-827 3161 > Internet: goertzek@wangfed.com > > +-----------------------------------------+ > | Human history becomes more and more a | > | race between education and catastrophe. | > | - H.G. Wells | > +-----------------------------------------+ > > -- Jon F. Spencer spencerj@rtp.dg.com (uunet!rtp.dg.com!spencerj) Data General Corp. Phone : (919)248-6246 62 T.W. Alexander Dr, MS #119 FAX : (919)248-6108 Research Triangle Park, NC 27709 Office RTP 121/9 Reality is an illusion - perception is what counts. No success can compensate for failure at home. President David O. McKay ***** UCC 1-207 ******** From firewalls-owner Mon Dec 4 15:57:10 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA10606 for firewalls-outgoing; Mon, 4 Dec 1995 14:23:37 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id OAA10572 for ; Mon, 4 Dec 1995 14:23:26 -0800 (PST) Message-Id: <199512042223.OAA10572@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA248905843; Tue, 5 Dec 1995 09:24:03 +1100 From: Darren Reed Subject: Re: etcp missing from ftp To: jtaylo3@gl.umbc.edu (Randy Taylor) Date: Tue, 5 Dec 1995 09:24:03 +1100 (EDT) Cc: Firewalls@GreatCircle.COM (Firewalls Mailing List) In-Reply-To: <199512041423.JAA16188@umbc8.umbc.edu> from "Randy Taylor" at Dec 4, 95 09:23:21 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I stuffed up the ftp URL. it should have been: ftp://coombs.anu.edu.au/pub/net/misc/etcp.tar.gz darren From firewalls-owner Mon Dec 4 16:01:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA08666 for firewalls-outgoing; Mon, 4 Dec 1995 13:38:13 -0800 (PST) Received: from svcs1.digex.net (svcs1.digex.net [204.91.197.224]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA08661 for ; Mon, 4 Dec 1995 13:38:09 -0800 (PST) Received: from GWFX1.sysorex.com (gwfx1.sysorex.com [204.192.18.20]) by svcs1.digex.net (8.6.12/8.6.12) with SMTP id QAA17840; Mon, 4 Dec 1995 16:38:50 -0500 Received: from ccMail by GWFX1.sysorex.com (SMTPLINK V2.10.08) id AA818123151; Mon, 04 Dec 95 16:22:26 EST Date: Mon, 04 Dec 95 16:22:26 EST From: "Dave Druitt" Message-Id: <9511048181.AA818123151@GWFX1.sysorex.com> To: firewalls@greatcircle.com, "A. Padgett Peterson, P.E. Information Security" Subject: Re[2]: SDI etc. (3of3) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Padgett reminisces: pps anyone who thinks "rocket science" is easier than the Orange Book has never studied transonic gas flow charactoristics in a convergent-divergent 2-D vectoring nozzle or choked-flow reversion waves in ducts of high- bypass turbofans. Does come in handy for "rule bending" in race car fuel injections. Used to get over 900 cfm out of a 600 cfm Rochester FI. Cram enough air in and a small block Chevvy will wind to the moooon 8*). _________________________________ It's that durn cavitation in the y-lines that'll getcha every time... Dave Druitt From firewalls-owner Mon Dec 4 16:05:47 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA10485 for firewalls-outgoing; Mon, 4 Dec 1995 14:22:03 -0800 (PST) Received: from flying.fish.com (flying.fish.com [140.174.97.13]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id OAA10480 for ; Mon, 4 Dec 1995 14:21:58 -0800 (PST) Received: (from zen@localhost) by flying.fish.com (6.0.1/8.7.1.3) id OAA01732; Mon, 4 Dec 1995 14:22:51 -0800 (PST) Date: Mon, 4 Dec 1995 14:22:51 -0800 (PST) From: d Message-Id: <199512042222.OAA01732@flying.fish.com> To: firewalls@greatcircle.com In-reply-to: morph_1@netaxs.com's message of 4 Dec 1995 12:50:31 -0800 Subject: Re: Small Demo scanner required. Organization: Vicious Fishes Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > On Mon, 4 Dec 1995, Anton J Aylward wrote: > > I'm looking for a small, possibly MS-windows based, scanner. > > Its intended to be used as a diversion from Powerpoint > > during presentations... I don't know of any ms/mac based scanners, although I'd like to hear of any. You could run unix (maybe free BSD or linux) on a partition. However, real-time scanning isn't likely to get you much, unless their machine is really broken - scanning typically takes a fair bit of time. It's much more effective to get the attendance list beforehand and do it in advance. Putting up some slides or results of a scanner/security tool can be pretty cool if it's the machine of the person hosting the talk or something (assuming you have the ok, 'natch), or merely some simple stats. > How the hell do people like you get jobs? > Not to be insulting or anything. I never cease to be amazed about how nasty people can get. > if you think i was insulting i will sue. Simply idiotic, not insulting. > Morph (morph_1@nextas.com) Morph's Elite Research Labs, Inc. "Elite"? I always hoped that the elite would teach, rather than get their rocks off from putting down those that don't know. -- d (Far from elite, but with aspirations.) From firewalls-owner Mon Dec 4 16:24:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA12477 for firewalls-outgoing; Mon, 4 Dec 1995 15:11:01 -0800 (PST) Received: from quest-fw ([205.162.80.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id PAA12472 for ; Mon, 4 Dec 1995 15:10:58 -0800 (PST) From: todd@questinc.com Received: from questinc.com (whitewater [198.176.161.21]) by quest-fw (8.6.12/8.6.12) with SMTP id PAA09191 for ; Mon, 4 Dec 1995 15:11:09 -0800 Received: by questinc.com (5.x/SMI-SVR4) id AA02178; Mon, 4 Dec 1995 15:11:07 -0800 Date: Mon, 4 Dec 1995 15:11:07 -0800 Message-Id: <9512042311.AA02178@questinc.com> To: firewalls@greatcircle.com Subject: Packet Filter Freeware Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Where can I find a freeware package that supports packet filtering. I primarily want to block access from internal users to nasty sites (i.e. sex.com). I am currently using the FWTK as a firewall. From firewalls-owner Mon Dec 4 17:24:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA16201 for firewalls-outgoing; Mon, 4 Dec 1995 16:37:30 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id QAA16196 for ; Mon, 4 Dec 1995 16:37:24 -0800 (PST) Message-Id: <199512050037.QAA16196@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA017963856; Tue, 5 Dec 1995 11:37:36 +1100 From: Darren Reed Subject: Re: Filtering fragmented IP frames To: pdrolet@CyberSecure.Com (Patrick Drolet) Date: Tue, 5 Dec 1995 11:37:36 +1100 (EDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <199512042118.QAA01426@CyberSecure.Com> from "Patrick Drolet" at Dec 4, 95 04:18:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In some mail from Patrick Drolet, sie said: > > Filtering IP frames is quite simple. > Filtering UDP/IP or TCP/IP frames seems quite simple... > > The problem filtering TCP/IP is fragmentation; How does a firewall (or even a > Cisco Secure Router) manage to filter fragmented IP frames knowing that the > TCP or UDP header is only on the first frame ? Read RFC 791 which describes IP and fragmentation. Hint: it's very easy. darren p.s. I hope your company (cybersecure ?) isn't writing a packet filter from scratch... From firewalls-owner Mon Dec 4 17:54:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id RAA19822 for firewalls-outgoing; Mon, 4 Dec 1995 17:31:40 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id RAA19813 for ; Mon, 4 Dec 1995 17:31:32 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id UAA10113; Mon, 4 Dec 1995 20:31:51 -0500 Date: Mon, 4 Dec 1995 20:31:51 -0500 Message-Id: <199512050131.UAA10113@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "william.wells" From: Anton J Aylward Subject: Re: FW: chroot/setuid vs type enforcement Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 08:23 4/12/95 CST, "william.wells" wrote: > --Having worked on systems where security was a very high concern for years, >I personnel disagree that they take a greater level of skill. (That is, >unless the security mechanisms aren't well integrated or one is trying to >get around the security.) What security does require is attention. If >someone comes from a "wide open" environment, then working in a security >conscious environment will take some effort to learn but so does learning >about chroot/setuid and other 'changes' made in firewalls. Being security >conscious probably isn't a bad thing for any programmer. Quite, but I'd phrase it differently. Someone once said "any fool can write a compiler for a sytactically correct program". Just so with secure kernels. I'd use the term imagination. The programmer - or designer depending on how you work - has to imagine all the things that could go wrong. For example, the buffer overflow problems we've seen between the Morris work and other things recently were becuase the programmer never imagined the application would have to deal with perverse SOBs shoving extra stuff down. Then when we saw how the Morris worm worked, we were collectively guilty of not imagining it was a technique which could be used elsewhere. /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Mon Dec 4 18:35:58 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id RAA20383 for firewalls-outgoing; Mon, 4 Dec 1995 17:47:02 -0800 (PST) Received: from gw.alantec.com (gw.alantec.com [147.128.64.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id RAA20350 for ; Mon, 4 Dec 1995 17:46:36 -0800 (PST) Received: from mailroom.alantec.com (mailroom.alantec.com [147.128.48.23]) by gw.alantec.com with ESMTP id RAA05100 (8.7.1/IDA-1.6 for ); Mon, 4 Dec 1995 17:13:09 -0800 (PST) Received: from paperboy.alantec.com by mailroom.alantec.com (8.7.1/ALTC-sm8-1.9) id RAA13644; Mon, 4 Dec 1995 17:13:08 -0800 (PST) for Received: by paperboy.alantec.com (8.7.1/ALTC-sm8-1.9) id RAA20893; Mon, 4 Dec 1995 17:13:07 -0800 (PST) for firewalls@greatcircle.com Received: from tango.alantec.com by paperboy.alantec.com (8.7.1/ALTC-sm8-1.9) id RAA20889; Mon, 4 Dec 1995 17:13:06 -0800 (PST) for Received: by tango.alantec.com (8.7.1/ALTC-sm8-1.8) id RAA04461; Mon, 4 Dec 1995 17:13:05 -0800 (PST) To: alantec-mail-firewall@tango.alantec.com Path: alantec.com!not-for-mail From: paul@alantec.com (G. Paul Ziemba) Newsgroups: alantec.mail.firewall Subject: Re: Filtering fragmented IP frames Date: 4 Dec 1995 17:13:04 -0800 Organization: Alantec, San Jose, CA Lines: 17 Message-ID: <4a06b0$4bb@tango.alantec.com> References: <4a000k$jos@paperboy.alantec.com> X-Newsreader: NN version 6.5.0 #7 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk pdrolet@CyberSecure.Com (Patrick Drolet) writes: >The problem filtering TCP/IP is fragmentation; How does a firewall (or even a >Cisco Secure Router) manage to filter fragmented IP frames knowing that the >TCP or UDP header is only on the first frame ? In theory, if there is not a complete packet to reassemble at the destination, it won't be delivered to the higher layers. Router filters operate on the assumption that they do not need to drop all fragments of a packet, only some (or one) of them. -- Paul Ziemba, software archaeologist: paul@alantec.com alantec!paul "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." - George Bernard Shaw From firewalls-owner Mon Dec 4 18:38:10 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id SAA21438 for firewalls-outgoing; Mon, 4 Dec 1995 18:12:08 -0800 (PST) Received: from tuna.wang.com (tuna.wang.com [150.124.136.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id SAA21433 for ; Mon, 4 Dec 1995 18:12:04 -0800 (PST) Received: from elf5.wang.com (fitz@elf5.wang.com [150.124.4.18]) by tuna.wang.com (8.6.12/8.6.12tf1) with ESMTP id VAA17066 for ; Mon, 4 Dec 1995 21:12:58 -0500 Received: (from fitz@localhost) by elf5.wang.com (8.6.12/8.6.12tf1) id VAA21523; Mon, 4 Dec 1995 21:12:57 -0500 Date: Mon, 4 Dec 1995 21:12:57 -0500 From: Tom Fitzgerald Message-Id: <199512050212.VAA21523@elf5.wang.com> To: firewalls@greatcircle.com Subject: Re: Filtering fragmented IP frames Sender: firewalls-owner@GreatCircle.COM Precedence: bulk pdrolet@CyberSecure.Com (Patrick Drolet) writes: > The problem filtering TCP/IP is fragmentation; How does a firewall (or even a > Cisco Secure Router) manage to filter fragmented IP frames knowing that the > TCP or UDP header is only on the first frame ? It's always safe (with one exception) to forward non-initial fragments, and only test TCP/UDP fields in the initial fragment. If the initial fragment gets filtered out then the datagram can't be reassembled, so the rest of the fragments will eventually be thrown away too. The one exception to this is a TCP packet fragment that starts in the middle of the TCP header. See RFC 1858 for details. -- Tom Fitzgerald 1-508-967-5278 Wang Labs, Billerica MA, USA fitz@wang.com From firewalls-owner Mon Dec 4 19:10:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id SAA22392 for firewalls-outgoing; Mon, 4 Dec 1995 18:29:56 -0800 (PST) Received: from staff.cs.su.OZ.AU (staff.cs.su.OZ.AU [129.78.8.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id SAA22367 for ; Mon, 4 Dec 1995 18:29:46 -0800 (PST) Message-Id: <199512050229.SAA22367@miles.greatcircle.com> Received: from staff.cs.su.oz.au by staff.cs.su.OZ.AU (mail from rex for firewalls@GreatCircle.COM) with MHSnet; Tue, 05 Dec 1995 13:30:31 +1100 Date: Tue, 05 Dec 1995 13:29:20 +1000 From: rex@staff.cs.su.oz.au (Rex di Bona) Subject: Re: Netra and Firewall-1 To: firewalls@GreatCircle.COM Reply-To: rex@cs.su.oz.au Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > From: joe.reeves@imail.exim.gov > > Any ideas on getting FireWall-1 v1.2.1 configured on a Netra Server. > We have had all kinds of problems. Apparently, the Solaris OS is > scaled-down and alot of the commands on a regular Sparc 20 arent > there. I think the manual was written assuming your on a Sparc. > > Any inside hints on installation. Thanks The Netra CD has all the Solaris packages on it. When I'm faced with a Netra I shove the CD into the drive, mount it manually (no vold), and pkgadd away, adding packages that contain the programs I'm looking for (I usually start with the man pages). If the machine is going to be used as a firewall you may want to clean up afterwards. Rex. From firewalls-owner Mon Dec 4 19:26:07 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id SAA21560 for firewalls-outgoing; Mon, 4 Dec 1995 18:14:52 -0800 (PST) Received: (mcb@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id SAA21554; Mon, 4 Dec 1995 18:14:50 -0800 (PST) Message-Id: <199512050214.SAA21554@miles.greatcircle.com> From: mcb@greatcircle.com (Michael C. Berch) Date: Mon, 4 Dec 1995 18:14:49 +0000 In-Reply-To: X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: firewalls Subject: Re: A1 Systems? Cc: brent Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Please -- no responses on this one, OK? I have admonished the poster by private mail and would like this not to turn into a free-for-all. -- Michael C. Berch Postmaster and List Manager, Great Circle Associates mcb@greatcircle.com ---------------- Morph writes: > On Mon, 4 Dec 1995, Lisa M. Jaworski wrote: > > > I can't help feel inflamed that people outside of TIS are making > > been burned in the course of their employment is ludicrous. I worked > > with Marcus for the duration of his time at TIS and I feel honor-bound > > VERY GOOD TERMS, both on a technical basis and a personal level with > > everyone who knew him. Anyone who thinks otherwise & would say so publicly > > is clearly wacko. Obviously, Marcus has already defended himself but as a > > opinions, & personality, I think this bears repeating. > > > > Lisa J. > > > > haw haw, he get's women to stick up for him. what a pathetic moron. > > sheesh. > > and i ain't no wacko. if u call me a wacko i will sue. > > -- > ---------------------------------------------------------------------------- > Morph (morph_1@nextas.com) Morph's Elite Research Labs, Inc. > From firewalls-owner Mon Dec 4 19:56:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id SAA22439 for firewalls-outgoing; Mon, 4 Dec 1995 18:30:06 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id OAA00109 for ; Sun, 3 Dec 1995 14:45:41 -0800 (PST) Message-Id: <199512032245.OAA00109@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA095490467; Mon, 4 Dec 1995 09:41:07 +1100 From: Darren Reed Subject: Re: BoS: IP Port Scan Detector. To: mcn@EnGarde.com (Mike Neuman) Date: Mon, 4 Dec 1995 09:41:07 +1100 (EDT) Cc: ipfilter@coombs.anu.edu.au, bugtraq@crimelab.com, firewalls@greatcircle.com In-Reply-To: <199512032152.PAA14372@guardian.EnGarde.com> from "Mike Neuman" at Dec 3, 95 03:52:24 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In some mail from Mike Neuman, sie said: > > Three things: > > >Darren Reed wrote: > > It doesn't look for Stealth Scans by their signiture (half-open connections > > and using ACKs, etc), but just registers all packets sent to a select > > number of ports. The higher the number of ports `hit' by a given host, > > the higher its score for probability of having done a port scan. > > 1) I haven't looked at the code, but it would seem a couple things were > significant in this approach: > - What happens if a firewall is blocking some of the "sensitive" ports? > (e.g. ports 1-100 but not 23 get scanned) My feeling is that although port scans occur across (usually) the entire spectrum of 0-1023, the actual number of services that are within this range that provide a foot hold for intruders isn't as high as 1024. What do you care if someone knows you have echo and chargen defined on some machine ? If they skip telnet (assuming it is there), then they're actually skipping over a possible way in. Unfortunately, it doesn't deal with portmapper services (yet). With respect to ports being blocked, the usefullness of the software depends on where it's placed and the configuration of machines around it. Obviously, if you're running it on a host behind a router which blocks a whole heap of ports it isn't going to report anything useful to you. For IP firewalling done on Unix boxes, I believe this will work even if they're turned on due to all packages that I've seen doing it inside ip_output/ip_input (or that level) rather than at the level where BPF/NIT operate. I don't know about Linux, however. > - Time would seem to be significant. (e.g. What if I scan a new port > every 5 > minutes (or whatever)) And if the timing is too small, a busy server > will most likely get flagged as being scanned. This is something that I'm going to re-visit. I think if you increase the weighting of ports which you have closed off on a server (such as X or rexecd/rexd) then scans against services, which aren't going to be used by any application, become more obvious. This is probably a good area for some more research :) The current behaviour is to ignore time: registered hits are stored (to disk) every time x packets match the ports you consider sensitive and the reporting program reads all the logs. Each IP# is only recorded once per service in each log. My feeling is that time is unimportant, overall. If you just want to catch SATAN style scanning then use Courtney or something similar. > 2) You didn't mention if your half-open port scanner was available. I wrote > one a long time ago which is freely available. If anyone would like to grab a > copy of it, you can find it in the intrusion section of my home page. It only > runs under SunOS 4.x, but it's basically just a proof of concept. :-) Enough people have it :( A modified version (which just generates strange packets) is available in the IP filter package and is provided as a tool to test the integrity of the parent package. (look inside ftp://coombs.anu.edu.au/pub/net/firewall/ip-filter/ip_fil2.8.2.tar.gz at ipsend). > 3) Are firewall logging packages vulnerable to this? (ie. Does the firewall > only log/alert on the existance of a fully established connection, or merely > on the first SYN?) It takes notice of _all_ TCP packets, not just SYN, ACK'd packets or some other combination. Those "packets without TCP flags" are not a problem as it doesn't care about them and the port parameters must be preset in the first fragment of a TCP connection. darren From firewalls-owner Mon Dec 4 20:24:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA27148 for firewalls-outgoing; Mon, 4 Dec 1995 20:12:19 -0800 (PST) Received: from relay.ashton.csc.com (relay.ashton.csc.com [20.2.54.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id UAA27136 for ; Mon, 4 Dec 1995 20:12:13 -0800 (PST) Received: by relay.ashton.csc.com; id XAA16522; Mon, 4 Dec 1995 23:13:37 -0500 Received: from mccoy.ashton.csc.com(20.2.51.2) by relay.ashton.csc.com via smap (g3.0.1) id sma016520; Mon, 4 Dec 95 23:13:28 -0500 Received: (from ckostick@localhost) by mccoy.ashton.csc.com (8.6.9/8.6.9) id XAA13789 for firewalls@greatcircle.com; Mon, 4 Dec 1995 23:19:57 -0500 From: Chris Kostick Message-Id: <199512050419.XAA13789@mccoy.ashton.csc.com> Subject: Re: Filtering fragmented IP frames To: firewalls@greatcircle.com Date: Mon, 4 Dec 1995 23:19:56 -0500 (EST) In-Reply-To: <199512042118.QAA01426@CyberSecure.Com> from "Patrick Drolet" at Dec 4, 95 04:18:05 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > Filtering IP frames is quite simple. > Filtering UDP/IP or TCP/IP frames seems quite simple... > > The problem filtering TCP/IP is fragmentation; How does a firewall (or even a > Cisco Secure Router) manage to filter fragmented IP frames knowing that the > TCP or UDP header is only on the first frame ? Well here's the assumption. The first fragment, FRAG_OFF = 0, would contain the TCP or UDP segment/datagram header and therefore allow the fragment through only if it passed the filter rules. To allow succeeding fragments through a general rule can be written such that IF FRAG_OFF > 0 THEN allow packet through This is 'supposedly' a safe assumption since the succeeding fragments that did make it to the destination could not be reassembled and therefore would be rendered useless. This can be a bad assumption. RFC 1858 points out a tiny fragment attack that can potentially get around this type of filtering and a prevention method for filtering the attack. -- Chris Kostick CSC From firewalls-owner Mon Dec 4 20:54:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA28779 for firewalls-outgoing; Mon, 4 Dec 1995 20:33:24 -0800 (PST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id UAA28755 for ; Mon, 4 Dec 1995 20:33:10 -0800 (PST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id UAA17032; Mon, 4 Dec 1995 20:33:15 -0800 Message-Id: <199512050433.UAA17032@puli.cisco.com> To: pdrolet@cybersecure.com Cc: firewalls@greatcircle.com Date: Mon, 04 Dec 1995 20:33:15 -0800 From: Paul Traina Sender: firewalls-owner@GreatCircle.COM Precedence: bulk See RFC-1858, we cover this in detail there. >Date: Mon, 04 Dec 1995 16:18:05 -0500 >To: firewalls@GreatCircle.COM >From: Patrick Drolet >Subject: Filtering fragmented IP frames > >Filtering IP frames is quite simple. >Filtering UDP/IP or TCP/IP frames seems quite simple... > >The problem filtering TCP/IP is fragmentation; How does a firewall (or even a >Cisco Secure Router) manage to filter fragmented IP frames knowing that the >TCP or UDP header is only on the first frame ? > >Patrick. From firewalls-owner Mon Dec 4 22:31:07 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id WAA03339 for firewalls-outgoing; Mon, 4 Dec 1995 22:02:22 -0800 (PST) Received: from uuneo.neosoft.com (uuneo.neosoft.com [206.109.1.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id WAA03334 for ; Mon, 4 Dec 1995 22:02:18 -0800 (PST) Received: from ris1.UUCP (ficc@localhost) by uuneo.neosoft.com (8.7.3/8.7.1) with UUCP id LAA10274 for GreatCircle.COM!firewalls; Mon, 4 Dec 1995 11:19:08 -0600 (CST) Received: by ris1.nmti.com (smail2.5) id AA27094; 4 Dec 95 10:08:24 CST (Mon) Received: by sonic.nmti.com; id AA09310; Mon, 4 Dec 1995 09:38:27 -0600 From: peter@nmti.com (Peter da Silva) Message-Id: <9512041538.AA09310@sonic.nmti.com.nmti.com> Subject: Re: Linux/freeBSD & Firewalls for a Newbw :-) (fwd) To: iialan@iifeak.swan.ac.uk (Alan Cox) Date: Mon, 4 Dec 1995 09:38:27 -0600 (CST) Cc: newton:communica.com.au@iifeak.swan.ac.uk, firewalls@GreatCircle.COM In-Reply-To: from "Alan Cox" at Dec 4, 95 12:44:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > The Linux/FreeBSD firewalls are basically the same code. I wouldn't choose > either for a high security environment. Please, a packet filter is a tool. You can use the "IPFW" code in a firewall, or you can run the box as a bastion host and put the filters elsewhere. (where's mjr when you need him? Oh yes, waffling on about TCSEC...) From firewalls-owner Tue Dec 5 04:54:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id EAA12691 for firewalls-outgoing; Tue, 5 Dec 1995 04:35:07 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id EAA12682 for ; Tue, 5 Dec 1995 04:34:52 -0800 (PST) Message-Id: <199512051234.EAA12682@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA253536861; Tue, 5 Dec 1995 23:34:21 +1100 From: Darren Reed Subject: Re: FW: chroot/setuid vs type enforcement To: anton@the-wire.com (Anton J Aylward) Date: Tue, 5 Dec 1995 23:34:21 +1100 (EDT) Cc: william.wells@damark.com, firewalls@GreatCircle.COM In-Reply-To: <199512050131.UAA10113@psyche.the-wire.com> from "Anton J Aylward" at Dec 4, 95 08:31:51 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In some mail from Anton J Aylward, sie said: [...] > For example, the buffer overflow problems we've seen between the > Morris work and other things recently were becuase the programmer > never imagined the application would have to deal with perverse SOBs > shoving extra stuff down. Then when we saw how the Morris worm > worked, we were collectively guilty of not imagining it was a technique > which could be used elsewhere. A digression... It doesn't take imagination to look at a function or system call, the parameters it takes, and extremes of input. This is part of formal design/testing for software; or so I thought. gets() is not a case of imagining peverse input, but simply what is the range of legal input values and can my buffer handle them all ? Same for most buffer related code. Peverse input only matters when you start parsing it, sometimes producing unexpected output. If you read in input using fgets(), is there room for a NULL on the end ? Do you put one there, anyway ? Do you do this before searching for any text (such as newline) in the buffer ? IMHO, very simple things. At NS'95, on the Saturday morning there was a tute. "Security and the World Wide Web", taken by John Stewart of Cisco Systems, which had a largish section on programming using shells, perl and C, in a secure fashion. There wasn't anything astounding mentioned, nothing requiring imagination of weird input, except maybe for shells/perl and the presence of ``. Most of it was common sense when doing things like sprintf, strcpy, gets, etc. If you'd like a copy of the notes, you should be able to email the Network Security Institute (who ran it), at: nsi@fedunix.org The moral here is not necessrily be imaginative; just don't make assumptions that everything will be correct in the real world. darren From firewalls-owner Tue Dec 5 06:24:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA14316 for firewalls-outgoing; Tue, 5 Dec 1995 06:19:00 -0800 (PST) Received: from mail.Clark.Net (mail.clark.net [168.143.0.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id GAA14311 for ; Tue, 5 Dec 1995 06:18:56 -0800 (PST) Received: from clark.net (proberts@clark.net [168.143.0.7]) by mail.Clark.Net (8.7.1/8.6.5) with ESMTP id JAA08640; Tue, 5 Dec 1995 09:19:52 -0500 (EST) Received: (from proberts@localhost) by clark.net (8.7.1/8.7.1) id JAA26803; Tue, 5 Dec 1995 09:19:48 -0500 (EST) Date: Tue, 5 Dec 1995 09:19:47 -0500 (EST) From: "Paul D. Robertson" To: Morris cc: firewalls@GreatCircle.COM Subject: Re: tn3270 proxy summary In-Reply-To: <9512011250.AA03850@is000913.BELL-ATL.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Fri, 1 Dec 1995, Morris wrote: > Date: Fri, 1 Dec 1995 07:50:39 -0500 (EST) > From: Morris > To: firewalls@GreatCircle.COM > Subject: tn3270 proxy summary > > It would seem that tn3270 is just telnet and that a telnet proxy such > as the TIS telnet proxy will work just fine. Many thanks to all that > responded to query. > That depends on the telnetd implementation, and the proxy. I've not used the TIS proxy, but be aware that if you are connecting to one of the mainframe stack vendor's telnetd, it expects the terminal negoiation to be in EBCDIC, while the other does it in ASCII. In that case, I'd expect plug-gw to work as advertised. Paul. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts@clark.net which may have no basis whatsoever in fact." PSB#9280 From firewalls-owner Tue Dec 5 06:54:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA14582 for firewalls-outgoing; Tue, 5 Dec 1995 06:34:02 -0800 (PST) Received: from global.globale.net (global.ca [204.101.90.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA14570 for ; Tue, 5 Dec 1995 06:33:57 -0800 (PST) Received: from ÿ"»yÙ$ (ppp12.globale.net [204.101.90.12]) by global.globale.net (8.6.8.1/SCA-6.6) with SMTP id OAA06019 for ; Tue, 5 Dec 1995 14:31:22 GMT Message-Id: <199512051431.OAA06019@global.globale.net> From: Eric Date: Tue, 05 Dec 95 09:34:00 -800 To: firewalls@greatcircle.com Mime-Version: 1.0 X-Mailer: Mozilla/1.0N (Windows) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: http://globale.net/ Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I recently subscribed to the Firewalls mailing list and think that the topics discussed are of great value. However, I think that personal issues (Flames) sometimes reduce the level of quality. Now my question: Our shop is now debating whether Tacacs+ or Radius should be used for authentication. It seems to me that both protocols are similar in terms of functionnality. Would anyone have any suggestions as to which one would be best on the long run? Thank you in advance. Eric. From firewalls-owner Tue Dec 5 07:47:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA14661 for firewalls-outgoing; Tue, 5 Dec 1995 06:39:10 -0800 (PST) Received: from provider.ins.com ([199.0.194.125]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA14656 for ; Tue, 5 Dec 1995 06:39:05 -0800 (PST) Received: from mattpc.ins.com (dynamic236.ins.com [199.0.193.236]) by provider.ins.com (8.6.12/8.6.12) with SMTP id JAA00714; Tue, 5 Dec 1995 09:35:27 -0500 Date: Tue, 5 Dec 1995 09:35:27 -0500 Message-Id: <199512051435.JAA00714@provider.ins.com> X-Sender: waugh@provider.ins.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jerry L. Edmiston" From: Matthew Waugh Subject: Re: (no subject) Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk This is not an SMAP/SMAPD problem - the problem is with the sendmail.cf on your system. It is this sendmail that is connecting back to "itself" (actually SMAP) and returning the message. It should not do so, it should just queue the message for later processing. My guess is (and it ain't much more than that) is that you are using DNS MX records in such a way that your sendmail is realising that it cannot deliver directly to the host, perusing the MX records, and deciding it will send the message to your SMAP host since from an MX point of view it appears to be "closer". Solutions are many and varied and depend on what your current sendmail.cf looks like and how your DNS is configured, but I believe you'll find that it is your sendmail re-connecting to SMAP, and you need to stop that happening to stop the SMAP/SMAPD loop. Hope this helps, any questions or if I can help further let me know. Mat At 01:57 PM 12/4/95 -0800, you wrote: >I am running smap and smapd on the firewall. Mail comes in with one of >two types of addesses, userid@domain.com or userid@host.domain.com. Mail >comes into the firewall and is passed to the mailhost if a host name >is not specified. Sendmail.cf re-writes the address, via the alaises >file, and deliveres to the host. If a host is specified, an attempt is >made to foward the mail to that host from the firewall server. This is >fine unless that particular host is 'down'. In this case, the mail seems >to be getting into a loop within smap and smapd on the firewall. If the >mailhost (which only runs sendmail, not smap and smapd) attempts to >deliver the mail to the 'downed' host, sendmail reconizes this and places >the mail in the 'mqueue' file which is what it should do. Our theroy is >that sendmail gives the mail back to smap, which stuffs it in his >directory for smapd, smapd retrieves the message and gives it to >sendmail and the loop continues until 30 hops occurre, 1 per minute, and >the message is bounced back to the sender. Are we on the right track >and if we are is there anyway to tell smap/smapd that the host is not >reachable and to store the message until a later time, such as what >sendmail does with un-deliverable mail and the mqueue file...please >help...jle9@eci-esyst.com > > > > -- Matthew Waugh Matthew_Waugh@ins.com INS - Raleigh, NC Pager: 800-739-1504 From firewalls-owner Tue Dec 5 07:54:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA14400 for firewalls-outgoing; Tue, 5 Dec 1995 06:23:58 -0800 (PST) Received: from gateway.damark.com (GATEWAY.DAMARK.COM [204.17.145.230]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA14395 for ; Tue, 5 Dec 1995 06:23:54 -0800 (PST) Received: by gateway.damark.com; id IAA14874; Tue, 5 Dec 1995 08:24:46 -0600 Received: from unknown(172.31.254.231) by gateway.damark.com via smap (g3.0.1) id sme014867; Tue, 5 Dec 95 08:24:20 -0600 Received: by damark.com (5.65/1.2-eef) id AA29851; Tue, 5 Dec 95 08:22:45 -0600 Message-Id: <9512051422.AA29851@damark.com> From: "william.wells" To: Anton J Aylward Subject: Re: FW: chroot/setuid vs type enforcement Date: Tue, 05 Dec 95 08:18:00 CST Sender: firewalls-owner@GreatCircle.COM Precedence: bulk My new comments are at the end. ---------------------------------------------------------------------------- -- Anton J Aylward wrote: >At 08:23 4/12/95 CST, "william.wells" wrote: > --Having worked on systems where security was a very high concern for years, >I personnel disagree that they take a greater level of skill. Being security >conscious probably isn't a bad thing for any programmer. Quite, but I'd phrase it differently. Someone once said "any fool can write a compiler for a syntactically correct program". Just so with secure kernels. I'd use the term imagination. The programmer - or designer depending on how you work - has to imagine all the things that could go wrong. For example, the buffer overflow problems we've seen between the Morris work and other things recently were because the programmer never imagined the application would have to deal with perverse SOBs shoving extra stuff down. Then when we saw how the Morris worm worked, we were collectively guilty of not imagining it was a technique which could be used elsewhere. --- What you say is very true. One of the things drilled into me when I was starting systems work is to check all parameters; don't assume anything. I remember writing one heavily used system program which was probably 80% bash-checking. We had resident hackers at the U who regularly attempted to find holes; if you had a weak program, they would usually find a way to trash it. We were taught to do all the system privileged stuff (if possible) before reading anything from the user and then to disable the privileges (which is what is going on with chroot and friends). Indeed, much of the preset code was in the IO buffers and was destroyed when we made the first read/write call. Since we had source to the system, we also added rudimentary type checking; some calls just didn't work unless the system was in a debug mode or some non-user accessible status bit was enabled. I was amazed when I started learning C code that most of the common calls don't check for length; the professor said that you just had to trust the user or write your own. (Actually, that still amazes me.) Basic "don't trust your caller" is one of the things I've seen programmers have to learn today (I made my share of mistakes here). Many learn on PCs where security generally isn't a concern- transitioning to systems where it is a concern isn't always easy. On the other hand (not in the case of firewalls), I wonder how many of the newer development programs allow for parameter checking? William Wells Manager, Technical Support Damark International, Inc From firewalls-owner Tue Dec 5 08:56:41 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA15518 for firewalls-outgoing; Tue, 5 Dec 1995 07:23:31 -0800 (PST) Received: from galby.ipp.pt (galby.ipp.pt [193.136.60.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA15511 for ; Tue, 5 Dec 1995 07:23:21 -0800 (PST) Received: by galby.ipp.pt (5.65/DEC-Ultrix/4.3) id AA14607; Tue, 5 Dec 1995 16:23:03 GMT Date: Tue, 5 Dec 1995 16:23:03 GMT Message-Id: <9512051623.AA14607@galby.ipp.pt> X-Sender: npll@galby.ipp.pt X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@greatcircle.com From: Nuno Leitao Subject: URGENT: Drawbridge and EtherExpress 16 | Compex boards. Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hello... I am sorry about the URGENT thing in the subject line, but this is really urgent ! I have Drawbridge 2.06b in a 386SX (a Goldstar) with 4MB ram, EtherExpress 16 and Compex EN2000 ethernet boards, NDIS drivers for both boards, and everything loads correctly, but... the boards just don't receive packets from either sides! Has anyone ever seen a problem like this ? The guys from TAMU have made a lot of efforts to solve my problem, but they haven't come up with a solution... I would apreciate specs. feedback from anyone running a stable Drawbridge configuration... Thank You All. --Nuno Leitao (nleitao@ipp.pt) / _/_ o __/ / o _ _ <_(_/__<____<_/_)_/_)_ / / ' ' Instituto para o Desenvolvimento Tecnologico, Instituto Politecnico do Porto, Porto, Portugal. From firewalls-owner Tue Dec 5 08:58:37 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA18259 for firewalls-outgoing; Tue, 5 Dec 1995 08:38:13 -0800 (PST) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id IAA18244 for ; Tue, 5 Dec 1995 08:37:42 -0800 (PST) Received: from rssi by relay5.UU.NET with SMTP id QQzsva23315; Tue, 5 Dec 1995 11:38:05 -0500 (EST) Received: from mel.rssi.com by rssi (4.1/SMI-4.1) id AA05577; Tue, 5 Dec 95 11:36:28 EST Received: by mel.rssi.com (5.x/SMI-SVR4) id AA00963; Tue, 5 Dec 1995 11:33:51 -0500 Date: Tue, 5 Dec 1995 11:33:51 -0500 From: rssi.com@rssi.rssi.com Message-Id: <9512051633.AA00963@mel.rssi.com> To: firewalls@greatcircle.com Subject: JAVA Mid-Atlantic Users Meeting Cc: Brad.VanOrden@rssi.com X-Sun-Charset: US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I just received an internal anouncement of a JAVA Mid-Atlantic Users Meeting in our Columbia, MD office. I know that JAVA has been a hot topic of debate on this list. I just wanted to let anyone in the area know about it in case they would like to attend and bring up their concerns and questions. It will be held 19 Dec at 5:30PM. A map to our facility is available from our web site (www.rssi.com). Please call John Zukowski if you plan on attending. Brad Van Orden Rapid Systems Solutions, Inc 410-312-0777 From firewalls-owner Tue Dec 5 10:08:05 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA19593 for firewalls-outgoing; Tue, 5 Dec 1995 09:30:01 -0800 (PST) Received: from gater3.sematech.org (GATER3.SEMATECH.ORG [192.73.53.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id JAA19582 for ; Tue, 5 Dec 1995 09:29:56 -0800 (PST) Received: from thecount.eng.sematech.org by gater3.sematech.org (8.6.12/F-1.9) with ESMTP id LAA11543; Tue, 5 Dec 1995 11:30:36 -0600 Received: from localhost.eng.sematech.org by thecount.eng.sematech.org (8.6.12/I-1.8) with SMTP id LAA08157; Tue, 5 Dec 1995 11:30:35 -0600 Message-Id: <199512051730.LAA08157@thecount.eng.sematech.org> X-Authentication-Warning: thecount.eng.sematech.org: Host localhost.eng.sematech.org didn't use HELO protocol Reply-to: Quentin.Fennessy@sematech.org To: holbrook@cic.net, kjrey@isi.edu, ssphwg@cert.sei.cmu.edu, admin@newrider.mhs.compuserve.com cc: "Firewalls Mailing List" Subject: Fair use? of RFC1244 in "Internet Firewalls and Network Security" Date: Tue, 05 Dec 1995 11:30:32 -0600 From: "Quentin Fennessy" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I have sent this note to: Paul Holbrook, Joyce Reynolds, an email address specified for comments on RFC1244, and an email address at the publishing company "New Riders Publishing," and cc'ed it to the Firewalls mailing list. This morning I worked on a network configuration problem. The problem involved security considerations, so I decided to use two resources: RFC1244 and a book I recently purchased, "Internet Firewalls and Network Security" (IFaNS). Internet Firewalls and Network Security Karanjit Siyan, PHD Chris Hare 1995 New Riders Publishing ISBN 1-56205-437-6 I recommend you _NOT_ buy this book! I opened up IFaNS and read chapter 3, titled "Designing a Network Policy." I found a lot of useful information in that chapter. I made notes about what I read. Then I printed out RFC1244 and started reading. Deja vu all over again! Chapter 3 of IFaNS appears to be blatant copying of RFC1244. On page 91 of IFaNS there is this note: RFC 1244 discusses site security policy in considerable detail. Many of the security policy issues in this chapter are based on the issues raised in this RFC. 'based on'? I'll say! Virtually all the useful information I found in chapter 3 of IFaNS was originally published in RFC1244. I am very disapointed in IFaNS. I have not read the rest of the book but now I wonder at its originality. Quentin Fennessy From firewalls-owner Tue Dec 5 10:28:50 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA18199 for firewalls-outgoing; Tue, 5 Dec 1995 08:34:46 -0800 (PST) Received: from SanFrancisco01.POP.InterNex.Net (SanFrancisco01.POP.InterNex.Net [205.158.3.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id IAA18178 for ; Tue, 5 Dec 1995 08:34:08 -0800 (PST) Received: from Anthros.Com ([205.158.235.130]) by SanFrancisco01.POP.InterNex.Net (post.office MTA v1.7 ID# 0-11028) with SMTP id AAA18109; Tue, 5 Dec 1995 08:34:38 -0800 Received: from phoebe.Anthros.Com by Anthros.Com (5.0/SMI-SVR4) id AA07184; Tue, 5 Dec 1995 08:32:13 -0800 Received: by phoebe.Anthros.Com (5.x/SMI-SVR4) id AA01123; Tue, 5 Dec 1995 08:29:33 -0800 Date: Tue, 5 Dec 1995 08:29:33 -0800 From: daemeonr@Anthros.Com@Anthros.Com Message-Id: <9512051629.AA01123@phoebe.Anthros.Com> To: jle9@qmgate.eci-esyst.com Subject: Re: (no subject) Cc: firewalls@greatcircle.com X-Sun-Charset: US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk You are trying to fix a problem caused by a bad design (which is also a security problem). Your mail should NOT include internal host names. Your internal sendmail.cf files should strip the host from the return address and forward it to your mail gateway. The gateway should then add your domain to it. Note my "duplicated" domain of daemeonr@Anthros.com@Anthros.com is not a side effect of this, I have been too lazy to finish configuring my own internal machine - children of the cobbler go barefoot and all of that ... => From firewalls-owner@GreatCircle.COM Mon Dec 4 18:59 PST 1995 => Date: Mon, 04 Dec 95 13:57:35 -0800 => From: "Jerry L. Edmiston" => Organization: ECI div of E-SYSTEMS => Mime-Version: 1.0 => To: firewalls@greatcircle.com => Subject: (no subject) => Content-Transfer-Encoding: 7bit => Sender: firewalls-owner@GreatCircle.COM => Content-Type: text/plain; charset="us-ascii" => => I am running smap and smapd on the firewall. Mail comes in with one of => two types of addesses, userid@domain.com or userid@host.domain.com. Mail => comes into the firewall and is passed to the mailhost if a host name => is not specified. Sendmail.cf re-writes the address, via the alaises => file, and deliveres to the host. If a host is specified, an attempt is => made to foward the mail to that host from the firewall server. This is => fine unless that particular host is 'down'. In this case, the mail seems => to be getting into a loop within smap and smapd on the firewall. If the => mailhost (which only runs sendmail, not smap and smapd) attempts to => deliver the mail to the 'downed' host, sendmail reconizes this and places => the mail in the 'mqueue' file which is what it should do. Our theroy is => that sendmail gives the mail back to smap, which stuffs it in his => directory for smapd, smapd retrieves the message and gives it to => sendmail and the loop continues until 30 hops occurre, 1 per minute, and => the message is bounced back to the sender. Are we on the right track => and if we are is there anyway to tell smap/smapd that the host is not => reachable and to store the message until a later time, such as what => sendmail does with un-deliverable mail and the mqueue file...please => help...jle9@eci-esyst.com => => From firewalls-owner Tue Dec 5 10:40:35 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA18431 for firewalls-outgoing; Tue, 5 Dec 1995 08:45:18 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA18409 for ; Tue, 5 Dec 1995 08:44:42 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id KAA17148; Tue, 5 Dec 1995 10:48:33 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id KAA17144; Tue, 5 Dec 1995 10:48:32 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id KAA25484; Tue, 5 Dec 1995 10:45:54 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id KAA06388; Tue, 5 Dec 1995 10:45:53 -0600 From: Rick Smith Message-Id: <199512051645.KAA06388@shade.sctc.com> Subject: Re: chroot/setuid vs type enforcement To: anton@the-wire.com (Anton J Aylward) Date: Tue, 5 Dec 1995 10:45:53 -0600 (CST) Cc: smith@sctc.com, firewalls@greatcircle.com In-Reply-To: <199512031701.MAA09771@psyche.the-wire.com> from "Anton J Aylward" at Dec 3, 95 12:01:31 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I wrote: > >Regarding Marcus' specific example: chroot() is a pitiful thing. I > >dislike any security mechanism that relies on an application to set > >protections up correctly anyway. And Anton J Aylward replied: > I think you're being a bit unreasonable. >Unless we're talking about an embedded system, we have to rely on not >just the OS, but the application and the complete operating >environment. If you're talking about using a General Purpose >Computing Platform (e.g. UNIX) then part of the deal is that it isn't >going to do 'security' things unless the programmer programs it that >way. And the environment is set up that way. A high security application (i.e. one that is likely to be subjected to serious attacks and needs strong integrity protection against these attacks) needs help from the underlying OS to limit the attack's potential damage. That's why the Orange Book put mandatory protection into B and A level systems -- the protection tries to enforce the security policy even in the face of misbehaving programs that try to violate it. That's what we do with Type Enforcement on Sidewinder. It's true that you can't do this with conventional operating systems. And I recognize that most people have never worked with a system where the underlying OS enforces security constraints that applications can't somehow bypass. But this is what is necessary to do it right when you want to provide a powerful, high security solution. > >Othewise you're just waiting for problems to emerge before fixing > >them-- chasing the problems instead of getting in front of them. > >This has little to do with "Formal handwaving" or the lack of it and >lot to do with Vendor's Attitudes. I depends on what you're used to. I've worked on systems where the formal handwaving gave us a way of evaluating system changes in the light of how they affected the security model. Since we had a security model and we respected it, it kept us from seriously breaking the underlying design. > >If the Unix kernel > >interface implemented an adequate protection model for what we're > >doing (it doesn't, which is why we put in TE) then the Formal > >Handwaving would provide an obvious benefit. >I blame the early people at Berkeley for a lot. Like Peter da Silva >points out, having the network calls bypass the convention of the file >system devices is a case in point. I have a hard time finding fault with a development team when they've failed to solve a problem they didn't design for. I wasn't there, but I inferred that the main objective of *all* network software development until quite recently has been to Get It Working, then to Get It Working Fast. The security issues weren't important or even very thorougly understood back then. >Rick, its not that I disagree with you wholheartedly. I just think >that you're ignoring some important issues. I think the people who >built the original UNIX were very smart. I also think that a lot of >mediocre talent has constructed some [baroque/riccoco] not so smart >edifices on top of it. If you're smart enough, you can build it >right. If not, you have to be humble enough to recognize it and rely >on the use of formal methods. The fundamental problem with achieving security objectives is that they're global properties of the system. All sorts of apparently mundane things can modify the system's security. A popular way to achieve objectives is to have a design czar that keeps a mental security model and uses it to judge design changes. This works well for commercial companies doing proprietary development (the original Unix model). It works horribly when development gets distributed across multiple sites and individuals, all with different objectives (the modern Unix model). I believe that an explicit, formal security model is the only thing that might have kept Unix from diverging so dramatically. Without it, developers had no way of judging the security implications of their design change. It wasn't like Thompson or some other guru got cloned and sent to Berkeley -- they had to develop their own inner guidance for judging design changes. To be honest, aren't we really discussing a security model for Unix that's been extracted in retrospect? We've identified a set of security problems and we reverse engineered to identify the design flaws underlying them. I think there are valuable lessons here, but let's not dump on 1980s developers for not solving 1990s problems. If they had a protection model (I don't think they really did) then they knew networking would affect it somehow. Instead of designing to meet a poorly understood threat environment they designed to tangible functional and performance requirements. I wish they had had a crystal ball and had done things right, but I can't blame them for the lack. Rick. smith@sctc.com secure computing corporation From firewalls-owner Tue Dec 5 10:48:53 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA18533 for firewalls-outgoing; Tue, 5 Dec 1995 08:53:39 -0800 (PST) Received: from SanFrancisco01.POP.InterNex.Net (SanFrancisco01.POP.InterNex.Net [205.158.3.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id IAA18528 for ; Tue, 5 Dec 1995 08:53:34 -0800 (PST) Received: from Anthros.Com ([205.158.235.130]) by SanFrancisco01.POP.InterNex.Net (post.office MTA v1.7 ID# 0-11028) with SMTP id AAA18570 for ; Tue, 5 Dec 1995 08:55:06 -0800 Received: from phoebe.Anthros.Com by Anthros.Com (5.0/SMI-SVR4) id AA07204; Tue, 5 Dec 1995 08:52:43 -0800 Received: by phoebe.Anthros.Com (5.x/SMI-SVR4) id AA01139; Tue, 5 Dec 1995 08:50:04 -0800 Date: Tue, 5 Dec 1995 08:50:04 -0800 From: daemeonr@Anthros.Com@Anthros.Com Message-Id: <9512051650.AA01139@phoebe.Anthros.Com> To: firewalls@greatcircle.com Subject: Re: FW: chroot/setuid vs type enforcement X-Sun-Charset: US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Recently, Darren Reed wrote: => => In some mail from Anton J Aylward, sie said: => [...] => > For example, the buffer overflow problems we've seen between the => > Morris work and other things recently were becuase the programmer => > never imagined the application would have to deal with perverse SOBs => > shoving extra stuff down. Then when we saw how the Morris worm => > worked, we were collectively guilty of not imagining it was a technique => > which could be used elsewhere. => => A digression... => => It doesn't take imagination to look at a function or system call, the => parameters it takes, and extremes of input. This is part of formal => design/testing for software; or so I thought. It does take (a) time, (b) knowledge that you need to look at (code for) boundary conditions, and (c) motivation. (a) assumes a reasonable development cycle (b) assumes experience (c) assumes experience (a) assumes competent management which pays for experience and allows for development costs. Lacking (a), you demotivate people to use (b) and (c). Get real you guys. A competent manager is perceived as such by his managers or he wouldn't get hired. How many upper managers are technically concerned let alone competent? Mostly they are skilled at convincing a customer to part with their money (hence the success of HP in the market place vis a vis Sun; hence the success of Oracle vis a vis Sybase; Hence ... ) => => gets() is not a case of imagining peverse input, but simply what is the => range of legal input values and can my buffer handle them all ? Same => for most buffer related code. Peverse input only matters when you start => parsing it, sometimes producing unexpected output. => I am working on a piece of OSF code that has *sigificant* problems with a lack of boundary conditions testing - and it represents a MAJOR change to the way security is/will be done on UNIX. The porting is done, the remaining weeks are to fix the boundary problems. How many of YOUR managers would slip a major OS release to fix the problems? Fortunately mine will (this time). Daemeon Reiydelle Certified Incompetent Programmer (Many are qualified, few are certified) => If you read in input using fgets(), is there room for a NULL on the end ? => Do you put one there, anyway ? Do you do this before searching for any => text (such as newline) in the buffer ? IMHO, very simple things. => => At NS'95, on the Saturday morning there was a tute. "Security and the => World Wide Web", taken by John Stewart of Cisco Systems, which had a => largish section on programming using shells, perl and C, in a secure => fashion. There wasn't anything astounding mentioned, nothing requiring => imagination of weird input, except maybe for shells/perl and the presence => of ``. Most of it was common sense when doing things like sprintf, strcpy, => gets, etc. If you'd like a copy of the notes, you should be able to email => the Network Security Institute (who ran it), at: => nsi@fedunix.org => => The moral here is not necessrily be imaginative; just don't make assumptions => that everything will be correct in the real world. => => darren => From firewalls-owner Tue Dec 5 11:59:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA22037 for firewalls-outgoing; Tue, 5 Dec 1995 10:46:03 -0800 (PST) Received: from usia.gov (XGATE.USIA.GOV [198.67.64.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA22032 for ; Tue, 5 Dec 1995 10:45:59 -0800 (PST) Received: from NetWare MHS (SMF70) by usia.gov via Connect2-SMTP 4.00; Tue, 5 Dec 95 13:46:38 -0500 Message-ID: <936AC4300136C8D1@usia.gov> Date: Tue, 5 Dec 95 13:42:41 -0500 From: "Lehrer, Neil" Organization: USIA To: firewalls@greatcircle.com Subject: tis and udp X-mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Sender: firewalls-owner@GreatCircle.COM Precedence: bulk hi, how does tis control udp connections? every time i see a review of a firewall there is controversy over this subject. cc to email would be great. Regards +++++++++++++++++++++++++++++++++++++++ + Neil Lehrer + U.S. Information Agency + Networks and Systems Support Division + + voice 202 619-0903 + fax 202 619-3883 + internet nlehrer@usia.gov + + "oh what a tangled net we weave + when we seek to retrieve." + +++++++++++++++++++++++++++++++++++++++ From firewalls-owner Tue Dec 5 12:04:08 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA21838 for firewalls-outgoing; Tue, 5 Dec 1995 10:40:07 -0800 (PST) Received: from [198.102.244.42] (pb520.greatcircle.com [198.102.244.42]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA21831; Tue, 5 Dec 1995 10:39:57 -0800 (PST) X-Sender: brent@miles.greatcircle.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Dec 1995 10:43:40 +0100 To: Quentin.Fennessy@sematech.org From: Brent@GreatCircle.COM (Brent Chapman) Subject: Re: Fair use? of RFC1244 in "Internet Firewalls and Network Security" Cc: "Firewalls Mailing List" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 11:30 AM 12/5/95, Quentin Fennessy wrote: >I have sent this note to: Paul Holbrook, Joyce Reynolds, an email >address specified for comments on RFC1244, and an email address at the >publishing company "New Riders Publishing," and cc'ed it to the >Firewalls mailing list. > >This morning I worked on a network configuration problem. The problem >involved security considerations, so I decided to use two resources: >RFC1244 and a book I recently purchased, "Internet Firewalls and >Network Security" (IFaNS). You might want to take a look at the security polices chapter (Chapter 11) in our book, by the way; I think you'll find it useful and to the point, and definitely not derivative of either RFC1244 or IFaNS. :-) -Brent ----------------------+----------------------------+------------------------ Brent Chapman | Great Circle Associates | 1057 West Dana Street Brent@GreatCircle.COM | http://www.greatcircle.com | Mountain View, CA 94041 ----------------------+----------------------------+------------------------ Internet Tutorials from the Experts! From firewalls-owner Tue Dec 5 12:37:07 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA21625 for firewalls-outgoing; Tue, 5 Dec 1995 10:37:17 -0800 (PST) Received: from [198.102.244.42] (pb520.greatcircle.com [198.102.244.42]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA21618; Tue, 5 Dec 1995 10:37:12 -0800 (PST) X-Sender: brent@miles.greatcircle.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Dec 1995 10:40:55 +0100 To: Quentin.Fennessy@sematech.org From: Brent@GreatCircle.COM (Brent Chapman) Subject: Re: Fair use? of RFC1244 in "Internet Firewalls and Network Security" Cc: "Firewalls Mailing List" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 11:30 AM 12/5/95, Quentin Fennessy wrote: >I have sent this note to: Paul Holbrook, Joyce Reynolds, an email >address specified for comments on RFC1244, and an email address at the >publishing company "New Riders Publishing," and cc'ed it to the >Firewalls mailing list. > >This morning I worked on a network configuration problem. The problem >involved security considerations, so I decided to use two resources: >RFC1244 and a book I recently purchased, "Internet Firewalls and >Network Security" (IFaNS). > > Internet Firewalls and Network Security > Karanjit Siyan, PHD > Chris Hare > 1995 > New Riders Publishing > ISBN 1-56205-437-6 > > I recommend you _NOT_ buy this book! > >I opened up IFaNS and read chapter 3, titled "Designing a Network >Policy." I found a lot of useful information in that chapter. I made >notes about what I read. > >Then I printed out RFC1244 and started reading. Deja vu all over >again! Chapter 3 of IFaNS appears to be blatant copying of RFC1244. >On page 91 of IFaNS there is this note: > > RFC 1244 discusses site security policy in considerable > detail. Many of the security policy issues in this chapter are > based on the issues raised in this RFC. > >'based on'? I'll say! Virtually all the useful information I found in >chapter 3 of IFaNS was originally published in RFC1244. I am very >disapointed in IFaNS. I have not read the rest of the book but now I >wonder at its originality. > >Quentin Fennessy As much as I despise the New Riders book (as you said, it's largely a cobbled-together knockoff of various publicly-available info), I'd point out that RFC1244 (and the RFCs in general) are NOT copyrighted... So while you and I may not like what they did, it was legal... -Brent ----------------------+----------------------------+------------------------ Brent Chapman | Great Circle Associates | 1057 West Dana Street Brent@GreatCircle.COM | http://www.greatcircle.com | Mountain View, CA 94041 ----------------------+----------------------------+------------------------ Internet Tutorials from the Experts! From firewalls-owner Tue Dec 5 13:09:01 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA25024 for firewalls-outgoing; Tue, 5 Dec 1995 12:25:02 -0800 (PST) Received: from gw1.att.com (gw1.att.com [192.20.239.133]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA25009 for ; Tue, 5 Dec 1995 12:24:57 -0800 (PST) Received: from vodka.sse.att.com (vodka.gc.att.com) by ig1.att.att.com id AA27969; Tue, 5 Dec 95 15:23:45 EST Message-Id: <9512052023.AA27969@ig1.att.att.com> From: mdr@vodka.sse.att.com Subject: Re: FW: chroot/setuid vs type enforcement To: avalon@coombs.anu.edu.au (Darren Reed) Date: Tue, 5 Dec 1995 15:29:28 -0500 (EST) Cc: anton@the-wire.com, william.wells@damark.com, firewalls@GreatCircle.COM In-Reply-To: <199512051234.EAA12682@miles.greatcircle.com> from "Darren Reed" at Dec 5, 95 11:34:21 pm X-Mailer: ELM [version 2.4 PL23-upenn2.7] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Anton J Aylward writes: > .... Then when we saw how the Morris worm > worked, we were collectively guilty of not imagining it was a technique > which could be used elsewhere. darren writes: > It doesn't take imagination to look at a function or system call, the > parameters it takes, and extremes of input. This is part of formal > design/testing for software; or so I thought. > I think we're probably all guilty of writing a bug or two somewhere. Trouble is, writing bug free programs is a lot harder to do than one might imagine. Going thru the code and inspecting for some set of know classifications of bugs may prove useful at eliminating some types of programming errors, but it will not prove that the program behaves according to its design requirements or that those requirements were correct. This is in general an intractable problem. Most of the papers and books that I have read about software test and reliability talk about statisitical tools for estimating the number of bugs remaining based on the size and complexity of the project and the amount of testing time whether in the lab or in the field. Basically I think that it's safer to assume that all applications contain bugs and that some of those bugs are security related. And that's not likely to change in the near future :( What can we do about it? A) write better applications: Search and fix known classifications of bugs such as buffer overflows Use software test/reliability methodologies B) Don't trust applications so much. 1) Monitor the application via some independent means. This could be auditing on a secure OS. Or it could be done by an application interpreter like Java. 2) Encapsulate the application to protect the rest of the world from damage. Virtual memory, chroot, type-enforcement, orange book systems all help 3) Grant permissions to applications sparingly on an as-needed basis. Unfortunately most OS's do not have adequate support for least privilege. But some do :) You may argue that now I'm trusting the OS which is bigger and uglier than the application. Being a belt-and-suspenders kind of guy when it comes to security, I recommend doing *both* A and B. Although sometimes people get lazy and will just "trust the OS". Mark Riggins Secure Systems Engineering AT&T Bell Labs From firewalls-owner Tue Dec 5 13:10:36 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA21700 for firewalls-outgoing; Tue, 5 Dec 1995 10:38:02 -0800 (PST) Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.6]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA21644 for ; Tue, 5 Dec 1995 10:37:42 -0800 (PST) Received: from smtpgty.saicuk.co.uk by flow.pipex.net with SMTP (PP); Tue, 5 Dec 1995 18:37:48 +0000 Received: by smtpgty.saicuk.co.uk with Microsoft Mail id <30C49027@smtpgty.saicuk.co.uk>; Tue, 05 Dec 95 18:32:07 GMT From: "Johnson-Bryden, Ian" To: "'firewalls@greatcircle.com'" Subject: RE: Napoleon and Clausewitz Date: Tue, 05 Dec 95 18:13:00 GMT Message-ID: <30C49027@smtpgty.saicuk.co.uk> X-Mailer: Microsoft Mail V3.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Anton J Aylward wrote: >Example: Napoleon was a BRILLIANT general. Von Clausawitz observed humbly, >and wrote the book which became the FORMAL METHODs for instructing military >officers. But that doesn't mean that other BRILLIANT generals cannot lead >troops to victory without an impact analysis, situation ananlysis, umpteen >simulations, dangling [...] mjr contributed a fasinating view of Napolean and Clauswitz (who may have had a weak claim on the Von). I have yet to see someone who springs from the womb fully formed and mature. Napoleon and anyone working in any area depends on the views of others and much of what is taught is theory but theory is only developing new thought from experience and/or observation. Napoleon was a cadet who studied artillery and applied theory brilliantly with style and creativity, but he also planned with great care and had teams of people to support him including theoreticians. He also put effort into promoting a range of 'standards' and formal methods. In the firewall situation a criteria is just one of a number of available tools to help a manager make decisions. The only problem comes when someone decides that B1 = 'Secret' without understanding what either means and just uses it as a way of diverting blame if something goes wrong. I would very much doubt that Napoleon woke up one morning and decided 'to hell with ploughing the field, lets go off and invade Germany', hoping that the troops would know how to fire the guns or even that someone would provide them. Unfortunately some people do seem to take that approach to information security and then wonder why they get bitten. In the same way I doubt that Napoleon equipped his troops with stones because guns were designed by theoreticians who calculated the weight of shot, the chamber pressure, the angle of elevation, etc., and the resulting product cost real money but the stones were just laying about and cost nothing. However some people do choose to use the stones of firewalling to avoid spending money. If it works for them good luck to them but if it does not then they only have themselves to blame. Ian J-B From firewalls-owner Tue Dec 5 13:16:31 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA21647 for firewalls-outgoing; Tue, 5 Dec 1995 10:37:47 -0800 (PST) Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.6]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA21636 for ; Tue, 5 Dec 1995 10:37:38 -0800 (PST) Received: from smtpgty.saicuk.co.uk by flow.pipex.net with SMTP (PP); Tue, 5 Dec 1995 18:37:30 +0000 Received: by smtpgty.saicuk.co.uk with Microsoft Mail id <30C49014@smtpgty.saicuk.co.uk>; Tue, 05 Dec 95 18:31:48 GMT From: "Johnson-Bryden, Ian" To: "'firewalls@greatcircle.com'" Subject: RE: Orange Book Irrelevant (was: A1 Systems?) Date: Tue, 05 Dec 95 17:34:00 GMT Message-ID: <30C49014@smtpgty.saicuk.co.uk> X-Mailer: Microsoft Mail V3.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 09:40 1/12/95 -0600, peter@nmti.com (Peter da Silva) wrote: >>> It's not about features, it's about assurance. >>> Commercial computing is about features (represented as functionality) >>> Therefore orange book is irrelevant to commercial computing. >> >>I have to say Marcus makes a good case. If assurance meant anything in the >>commercial world MS-DOS would have been sidelined by 1984. >> >>(sigh) >Anton commented: >Indeed, Sigh! >Feature selling - aka Bullet List selling (him what has the longest bullet >list >wins the sale) has come to dominate commercial computing. >This is adequately demonstrated when the winning list beats out the with 'features' which are irelevant to the task being performed. >(Is there a Dilbert cartton lurking there?) >Features have no place in a firewall. Actually, they have no place in >any product, if you subscribe to the old maxim "Its not a bug its a feature". >Every additional feature is an opportunity for something to go wrong. >For example, supose this whizz-bang firewall had SO MUCH POWER >that it was a waste to use it just a filter mechanism. Lets implement >a FTP server, and a WWW server on it as well. Whose? Well, the >vendor's version of course. (E.g. is a HP T500 platform with HP/UX V9. >See late CERT advisory for details.) Oh, and as FTP isn't suited to >everyone's taste, lets allow the files which are FTP'able to be NFS >mountable as well. And of course we have an X-Windows based >configuration tool running on this platform as well. [snip] Ok so we have a lot of bandwidth on the subject and some flame and emotion. Pity about the last 2 items. The basic fact is that no security criteria is perfect but it does provide a framework for testing and the framework is known. That should be better than some marketing claims from a vendor but it does add cost and can make a product historic. Some of the early attempts at high assurance levels have been very poor to bad. Equally some folk will regard C2 as the answer to the meaning of life particularly if they dont understand the criteria or the process. We could sit down and plan a new criteria for firewalls or any sub-system but then the world may not need and probably does not want yet another criteria and evaluation system. We already have the assurance folk wanting yet more Orange Book, the OSI folk claiming that security is just one critical element of OSI, and the QA folk claiming that the only part of risk management worth anything is a quality standard. In the end it does not much matter what a specific component can do or even what a complete system is capable of, but whether a particular user needs/wants what it can offer and that only comes from having a real risk policy which in turn is part of a real enterprise policy. The cost of the security is frequently given as a reason for not doing something on this list but in most postings 'cost' is really 'price'. If a door lock costs 5 cents and doent work its a wast of time buying it. If it costs $200 and it saves you $Ks its a good deal. The fact that the $200 door lock will do far more than you need is not important unless there is a $50 door lock on the market which will do everything you want, but then again you might find you spent $50 today and tomorrow you have to have something else which only comes from the $200 model. That means it cost you $250+ and if someone else found the hole first you may not be around to fix the problem. No product needs 'features' for the sake of features, but then you do need 'features' to get 'benefits' and we do need benefits to justify buying/using a product. Ian J-B From firewalls-owner Tue Dec 5 14:15:43 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA25538 for firewalls-outgoing; Tue, 5 Dec 1995 12:37:19 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA25530 for ; Tue, 5 Dec 1995 12:37:09 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id OAA24360; Tue, 5 Dec 1995 14:40:37 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id OAA24356; Tue, 5 Dec 1995 14:40:37 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id OAA29250; Tue, 5 Dec 1995 14:37:54 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id OAA11641; Tue, 5 Dec 1995 14:37:53 -0600 Date: Tue, 5 Dec 1995 14:37:53 -0600 From: Rick Smith Message-Id: <199512052037.OAA11641@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, anton@the-wire.com Subject: Re: Firewalls for the rest of us (was Re: A1 Systems) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Anton J Aylward writes about trading cost of loss against cost of security: > Visualize a graph if you will, two curves: A/x and B-(C/x) One curve > is the value of what you want to protect, the other is what you are > spending on protecting. You're plotting cost of security vs exposure. > Somewhere the curves cross, your cost of righ and your cost of > protection are in balance. Just to share a different point of view, I find it impossible to talk intelligently about only two axes. You need a third axis which shows operational needs/capabilities. The best analogy is physical security. You can always put your valuables in a box and embed it in a thick covering of concrete. This produces strong certainty regarding the physical location of your valuables but reduces their usability. Once you put a door in the box you're trading accessability against risk of loss. At the far end you have a store open to the public -- yes, you get ripped off regularly, but you treat it as a cost of doing business. The "security measures" you take are activities that minimize losses and recoup their costs. The tradeoff isn't risk against security costs, it's both against operational needs. After the Gulf War the defense establishment here decided they couldn't wait for trusted OSes on everyones' desktop before hooking Internet e-mail to classified network. They decided the risk of desktop subversion was acceptable in exchange for the benefits of network connectivity. So, they increased their exposure to attack at the same time the threat was growing. They traded off the increased risks against increased operational capabilities. Clausewitz could have predicted it. Rick. smith@sctc.com secure computing corporation From firewalls-owner Tue Dec 5 14:24:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA25452 for firewalls-outgoing; Tue, 5 Dec 1995 12:35:57 -0800 (PST) Received: from gatekeeper.alpharel.com (gatekeeper.ALPHAREL.COM [204.118.5.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA25447 for ; Tue, 5 Dec 1995 12:35:53 -0800 (PST) Received: (from mail@localhost) by gatekeeper.alpharel.com (8.6.8/8.6.6a) id MAA17760; Tue, 5 Dec 1995 12:36:50 -0800 Received: from optigfx.optigfx.com(147.203.1.30) by gatekeeper.alpharel.com via smap (V1.5mrm) id sma017758; Tue Dec 5 12:36:10 1995 Received: from visalia.optigfx.com by optigfx.optigfx.com (4.1/SMI-4.1-3) id AA20742; Tue, 5 Dec 95 12:33:07 PST Received: (from mrm@localhost) by visalia.optigfx.com (8.6.9/8.6.9) id MAA17022; Tue, 5 Dec 1995 12:33:05 -0800 Date: Tue, 5 Dec 1995 12:33:05 -0800 From: Mike Murphy Message-Id: <199512052033.MAA17022@visalia.optigfx.com> To: firewalls@GreatCircle.COM Subject: Re: Firewall Selection Criteria Cc: mrm@sceard.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Rick Smith says: > >Paul Merenbloom asks about firewall selection criteria: > >>What would you consider the top 5-10 issues? How does price >>sensitivity (or lack thereof) affect your rankings / issues? On what >>basis would (or have) you made your decisions (or guided others)? > >Here's a cut at some criteria: > >1) Compatibility with current operational requirements. Keep in mind >that requirements need to be traded off against security risks, and >vice versa. You can't be a slave to today's protocols but you can't >dismiss them either. > >2) Ability to block attacks. Do they block current ones, and what >is their strategy for handling future ones? > >3) Ability to monitor what's going on and report trouble in a timely >manner. Good records can help you identify emerging problems and >document serious attacks. Rapid incident response puts people against >the attacker -- humans are always better than machines. You know, I was trying to drive a 10 penny nail into a two-by-four with my thumb the other day, but I found that a hammer worked better than my thumb. Using the right machine for the job can be effective; humans are not always better than machines. Not withstanding, the criterion specified in 3) above seems important. > >4) Can the vendor provide convincing evidence that the product really >works as claimed? That's "assurance" -- some vendors just do a bit of >testing, others back their products with established development >processes, configuration control, design analysis, and top it off with >testing. Why buy from a garage shop? The reason to buy from a garage shop is that the product meets the requirements deemed important by the customer, including security, reliability, features, service, support, responsiveness, price, and performance. Ask the question the other way. Why not buy from a garage shop? If the product is good, why not buy? If the product isn't good, don't buy. Rather than the vendor providing "convincing evidence" and calling that "assurance", how's about the vendor providing a warranty with real teeth in it, say for example $1.25e6 US bonded indemnity if a verifiable breakin occurs. That would be assurance. "Convincing evidence" is marketing. Note that my statements above are argument by assertion. > >What about price? Well, look at what organizations spend for disaster >recovery setups. Even the most expensive firewall system is cheaper. I suspect that it is quite possible that many organizations use the "head in the sand" method of disaster recovery. I also suspect that many have the same approach to firewalling. All the negatives said, I think that secure computing corporation's type enforcement approach adds useful security. I also think that whether it is required or cost effective depends upon the environment. I really would like to see a meaningful warranty from vendors. Maybe for OS's, compiler's, applications, too. Fat chance :-) > >Rick. >smith@sctc.com secure computing corporation > Oops. I originally sent this to firewalls-owners. Clumsy, careless, no warranty, and not much assurance. -- Mike Murphy mrm@alpharel.com +1.619.625.3000 x265 ALPHAREL 9339 Carroll Park Drive San Diego, CA 92121 Any opinions above are mine and not those of my employer. From firewalls-owner Tue Dec 5 14:31:31 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA25267 for firewalls-outgoing; Tue, 5 Dec 1995 12:31:58 -0800 (PST) Received: from main.geminisecure.com (main.geminisecure.com [205.179.16.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA25262 for ; Tue, 5 Dec 1995 12:31:53 -0800 (PST) Received: (from leonard@localhost) by main.geminisecure.com (8.6.9/8.6.9) id MAA09838; Tue, 5 Dec 1995 12:25:54 -0800 Date: Tue, 5 Dec 1995 12:25:50 -0800 (PST) From: Leonard Miyata To: Rick Smith cc: firewalls@greatcircle.com, smith@sctc.com Subject: Re: Firewalls on MLS Systems (was: chroot) In-Reply-To: <199512051733.LAA07829@shade.sctc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk For everyone outthere, I hope this thread isn't getting too long Leonard Miyata On Tue, 5 Dec 1995, Rick Smith wrote: > I alluded to the problems of building a firewall on an MLS system > during our marathon chroot() discussion: > > >> Another problem, which is held by most alternatives that Marcus > >> noted in recent posts, is that correct behavior is in the hands > >> of the applications software. If the applications software goofs, > >> the protections are GONE. The underlying OS, whether it's a homespun > >> Unix kernel or a TCSEC evaluated platform, can't step in and help. > > and Leonard Miyata replied: > > >I would have to differ on the above statement. > >For those who don't know about Multi-Levl operating systems, a > >application for a "TRUSTED OS" is divided up into different modules with > >different levels of Security and integrity. The most common security > >model used from inter-process communications is that a 'Higher' level > >subject can 'Read Up' and 'Write Down' to a lower level subject, but the > >opposite is (with special exceptions) not allowed. This is enforced by > >multi-level Kernal and the CPU protected mode ring structure. > > > >The only exception to this is with 'Trusted Subjects' which > >1. Require special Kernal Calls. > >2. Can only be installed and configured in a off-line process. > >3. Should be minimal for Trust and Verification. > > This is indeed the textbook MLS Trusted Systems answer. But like all > textbook answers, it reads better than it performs. In our own > experience, we've noted the following about this particular approach: > > 1) There are only three domains: one each for the two environments > that communicate, and a "trusted" environment to handle all data > flow between the two. > > 2) Given that a firewall consists of nothing but software to mediate > data flow between an inside and an outside networking domain, this > places *ALL* of the firewall software in that one "trusted" domain. > This conflicts with requirement #3 of trusted subjects above unless > you limit the firewall to very basic capabilities. > > 3) If someone does manage to penetrate a piece of "trusted" > application software (not impossible given the amount in a full > function firewall) they can bypass the platform enforced permissions. > In any case, a prudent analyst takes this risk into account. > > 4) There's nothing in the standard model to prevent an attacker from > installing subverted software once an application has been penetrated. > > 5) Given that all networking software for a given network needs to > reside in the same protection domain, the system can't prevent one > application from attacking another. > > 6) Those "read up" and "write down" rules are an awkward thing to use > to construct the access paths an firewall needs. I've seen one or two > writeups on how to do it. But you have to fit the software to the > mechanism instead of vice versa. That's more risky, and limits the the > ways you can transfer information between domains. > > > Rick. > smith@sctc.com secure computing corporation > To provide an example of how to have a secure MLS application, we would have the following modules. 1. A Untrusted Internet I/O Port, at lets say system Low, responsible for LAN I/O functions. 2. We have a trusted Decision Making process at Guard High (single level). According to the internal Security Model, this Process can read Data (e.g. IP Packet) from Module 1 (and know how to avoid buffer overflow on its read). Process 2 would have to look at a System Low Flag to know when Process 1 has a Packet to process. Again according to the security Model, Process 1 has no rights to WRITE up to Module 2 (Protected by the Kernal) 3. We have a minimized Multi-Level Trusted Subject to Pass the Packet (assuming it has passed all the checks from Module 2) This is the only process that have write rights to the other modules, so for validation purposes it would be looked over very carefully. This process would pass the packet from process 1 to ... 4. A internal LAN process at somewhat system Low. This is the interior counterpart to 1 The above application would take full advantage of a Multi-Level Secure Kernal to save a application from its own features. If module 1 is ever compromised by a network attack, the Kernal will prevent any attempt to modify the core decision making process of module 2 This design also shows the main difference between a MLS application, and a convention design. For a conventional 'Single level application', potentially all the modules has access to the data (and each other) so for validation purposes, you would have to verify EVERYTHING. With a MLS application, only the Trusted Subject needs careful attention, and you can rely on the Kernal to protect the rest of the application from itself. Of course, as you point out, a MLS application does require more overhead then a conventional system (one of the reasons why we have a tendency towards multiple CPU boxes too). Then again, you can make the same comparision between a convention firewall, and routers with simple filtering rules. There will always be a cost for network security. Its not surprising that higher security does involve a higher cost. Hope this has been of help Leonard Miyata aka leonard@geminisecure.com GEMINI COMPUTERS INC Web page http://www.geminisecure.com From firewalls-owner Tue Dec 5 14:51:32 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA22950 for firewalls-outgoing; Tue, 5 Dec 1995 11:12:39 -0800 (PST) Received: from quebec.holstein.com (quebec.holstein.com [204.164.201.6]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id LAA22943 for ; Tue, 5 Dec 1995 11:12:34 -0800 (PST) Message-Id: <199512051912.LAA22943@miles.greatcircle.com> Received: by quebec.holstein.com (1.37.109.16/16.2) id AA178470771; Tue, 5 Dec 1995 14:12:51 -0500 From: Rob MacDonald Subject: TokenRing Firewalls To: firewalls@greatcircle.com Date: Tue, 5 Dec 95 14:12:50 EST Mailer: Elm [revision: 70.85.2.1] Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Another newbie joins the list. I have recently joined this group in hopes of seeing how to protect our network(s). In all the conversations I have been following, I have only seen refernces to Ethernet. I am wondering if there are any TokenRing based firewall packages? We are mostly TR with some Ethernet. We do have a couple of Cisco routers (2500 & 4000's). We are TR attached to our service provider thru the 2500. Any comments would be appreciated. TIA Robert MacDonald (rmacdonald@holstein.com) Holstein Association USA, Inc. (802) 254-6450 From firewalls-owner Tue Dec 5 15:03:39 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA26513 for firewalls-outgoing; Tue, 5 Dec 1995 13:09:19 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA26507 for ; Tue, 5 Dec 1995 13:09:11 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id PAA25369; Tue, 5 Dec 1995 15:12:49 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id PAA25365; Tue, 5 Dec 1995 15:12:48 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id PAA00374; Tue, 5 Dec 1995 15:10:05 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id OAA10854; Tue, 5 Dec 1995 14:10:56 -0600 Date: Tue, 5 Dec 1995 14:10:56 -0600 From: Rick Smith Message-Id: <199512052010.OAA10854@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, mjr@iwi.com Subject: Re: selection criteria? Newsgroups: security.firewalls References: <199512020409.XAA14695@switchblade.iwi.com> Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Marcus wrote about his "naughty game at a conference:" >.. I polled the room by show-of-hands as to what were the >important things they looked for in firewalls. Features, price, >and vendor reputation were pretty much the top categories. .. Vendor reputation has always been a big thing in defense security applications, probably even more so that TCSEC ratings. Rick. smith@sctc.com secure computing corporation From firewalls-owner Tue Dec 5 15:25:50 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA26505 for firewalls-outgoing; Tue, 5 Dec 1995 13:09:00 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA26500 for ; Tue, 5 Dec 1995 13:08:50 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id PAA25392; Tue, 5 Dec 1995 15:12:59 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id PAA25388; Tue, 5 Dec 1995 15:12:59 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id PAA00427; Tue, 5 Dec 1995 15:10:15 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id NAA10527; Tue, 5 Dec 1995 13:53:27 -0600 Date: Tue, 5 Dec 1995 13:53:27 -0600 From: Rick Smith Message-Id: <199512051953.NAA10527@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, bob@worldcom.com Subject: Re: Type enforcement vs chroot and buffers Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Robert Dana presents a summary of the differences between some modified version of chroot() and type enforcement as a security mechanism: >MJR and SCTC both agree that these other points of vulnerability in >the kernel interface should be identified and blocked. MJR advocates >making simple, ad hoc modifications to the kernel, such as preventing >chrooted processes from using socket(). This is often what firewall >vendors who claim to have "hardened" kernels do. This matches my understanding of what Marcus was saying and what I've seen and heard of other vendors' work. >SCTC's type enforcement is a formalized but complex (in comparison) >mechanism for accomplishing the same thing. We see Type Enforcement as taking a different approach. Instead of blocking existing vulnerabilities, it intends to establish a separate protection mechanism that we can depend on. People might see this as a quibble, but the point is that the semantics aren't specific to Unix. Also, I believe the apparent simplicity of chroot() is an illusion. The raw mechanism may be simple, but it's application is rather complicated. Maybe Type Enforcement looks more complex because it talks about more "things." But in practice that makes it easier since you talk *explicitly* about what you're protecting instead of trying to trick the file system into protecting the right stuff. >Type enforcement creates abstraction and more flexibility in >configuring the access controls, but introduces a lot more >security-critical code to verify. In both cases you need to review the entire Unix kernel source code. In the chroot() case you must also review the source code of every *application* that relies on it and verify application behavior against how chroot() works in a particular Unix kernel. So even if you do the work to convince yourself that you have a "good" chroot() you aren't finished. You have to verify every application's use of it every time the code gets "fixed" or a new application is ported. Also, the chroot() case is complicated by the fact that each piece of kernel code needs to be evaluated twice: once according to how it behaves in normal circumstances and once according to how it behaves under chroot(). Since all operational code always runs under Type Enforcement on Sidewinder, you're done once you look at the type enforced kernel code. But, in fact, I think the issue is moot because nobody will pay the money it takes to do an effective job of verifying firewall code. I don't think you achieve anything by performing a simple eyeballing of the code, especially on the industrial scale required to cover all the security critical code of a full function firewall. You can't train enough people to eyeball the code effectively to that level of detail. A realistic alternative is to do a "spec to code correspondence" analysis: another of those dreaded "Orange Book" procedures. Rick. smith@sctc.com secure computing corporation From firewalls-owner Tue Dec 5 15:50:35 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA28652 for firewalls-outgoing; Tue, 5 Dec 1995 14:06:26 -0800 (PST) Received: from [198.102.244.42] (pb520.greatcircle.com [198.102.244.42]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA28647; Tue, 5 Dec 1995 14:06:21 -0800 (PST) X-Sender: brent@miles.greatcircle.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Dec 1995 14:10:04 +0100 To: Quentin.Fennessy@sematech.org From: Brent@GreatCircle.COM (Brent Chapman) Subject: Re: Fair use? of RFC1244 in "Internet Firewalls and Network Security" Cc: "Firewalls Mailing List" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 10:40 AM 12/5/95, Brent Chapman wrote: >As much as I despise the New Riders book (as you said, it's largely a >cobbled-together knockoff of various publicly-available info), I'd point >out that RFC1244 (and the RFCs in general) are NOT copyrighted... So while >you and I may not like what they did, it was legal... Oh, hell... I didn't mean for that to go to the whole Firewalls list, only to Quentin personally; I guess I didn't check the outgoing headers carefully enough to notice the "Cc:". Mea culpa. I stand by what I said, though I wouldn't have put it so vehemently if I had been planning to post it to Firewalls. -Brent ----------------------+----------------------------+------------------------ Brent Chapman | Great Circle Associates | 1057 West Dana Street Brent@GreatCircle.COM | http://www.greatcircle.com | Mountain View, CA 94041 ----------------------+----------------------------+------------------------ Internet Tutorials from the Experts! From firewalls-owner Tue Dec 5 15:54:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA26956 for firewalls-outgoing; Tue, 5 Dec 1995 13:20:01 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA26950 for ; Tue, 5 Dec 1995 13:19:49 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id PAA25751; Tue, 5 Dec 1995 15:23:16 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id PAA25746; Tue, 5 Dec 1995 15:23:16 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id PAA00788; Tue, 5 Dec 1995 15:20:30 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id PAA12919; Tue, 5 Dec 1995 15:20:30 -0600 Date: Tue, 5 Dec 1995 15:20:30 -0600 From: Rick Smith Message-Id: <199512052120.PAA12919@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, leonard@geminisecure.com Subject: Re: FW: A1 Systems? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Leonard Miyata writes: >A Guard basicly takes blocks of Data from Multiple Single Level Ports, >labels and cryptoseals them, and passes them to a Multi Level Secure >port. Incoming Data blocks from the MLS port are then checked against the >internal write up rules, as well as the appropriate seal and label checks >and passed to the correct MSL Port. This sound more like an encryption unit than a Guard. Network level encryption units take packets or messages from one security context and protect it from disclosure (and maybe modification) before releasing it to another. People on the output side can't use the information released by the encryption unit -- it must be delivered to another unit that decrypts it. The guards I'm familiar with (SNS Mail Guard, ACCAT Guard, etc) take information from one security context and verify that it can be released to the other security context in a *usable* state. The security issues are *much* tougher for the site, the guard, and the machines that generate data the guard must pass judgement on. And it's much more like what a firewall usually does. Rick. smith@sctc.com secure computing corporation From firewalls-owner Tue Dec 5 16:27:34 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA27848 for firewalls-outgoing; Tue, 5 Dec 1995 13:48:04 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA27843 for ; Tue, 5 Dec 1995 13:47:57 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id PAA26769; Tue, 5 Dec 1995 15:51:40 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id PAA26765; Tue, 5 Dec 1995 15:51:39 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id PAA01807; Tue, 5 Dec 1995 15:48:54 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id PAA13753; Tue, 5 Dec 1995 15:48:54 -0600 Date: Tue, 5 Dec 1995 15:48:54 -0600 From: Rick Smith Message-Id: <199512052148.PAA13753@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, anton@the-wire.com Subject: Re: Orange Book Irrelevant (was: A1 Systems?) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Anton J Aylward proposes a list of obsolete Orange Book things: > The military ideas of "need to know", "heirarchy" and cells don't >apply in business. I disagree with the general statement, though I agree with what is meant. This stuff shows up all the time in businesses. Payroll systems or the CEO's office aren't integrated into the LAN. Some departments are locked after hours while others aren't. Subsidiaries compete, or people on special projects keep their stuff separate from other folks. On the other hand, I believe the Orange Book's attempt to cast it into technical security measures is irrelevant to the way businesses use computers. They won't put strong partitions into a single machine, rather they partition the networks. >Can someone suggest more reasons our current rainbow approach is >inapplicable? They insist that modeling be all-encompassing or be omitted entirely. It isn't compatible with QA concepts and standards like ISO 9000. Product improvement was pasted on with RAMP instead of built into the original criteria. And the One Good Thing: They provided an accepted criteria (at least for a little while) for establishing that a system met some defined security requirements. Given that no system is ever going to be perfectly secure (especially since the definition of same will vary with user and application) that's no small feat. I was talking to people about commercial crypto the other day, and that's a field that has this problem in spades. *No* standards exist for an "acceptable" commercial crypto system. Rick. From firewalls-owner Tue Dec 5 16:38:28 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA29454 for firewalls-outgoing; Tue, 5 Dec 1995 14:38:13 -0800 (PST) Received: from gater3.sematech.org (GATER3.SEMATECH.ORG [192.73.53.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id OAA29449; Tue, 5 Dec 1995 14:38:08 -0800 (PST) Received: from thecount.eng.sematech.org by gater3.sematech.org (8.6.12/F-1.9) with ESMTP id QAA16588; Tue, 5 Dec 1995 16:38:58 -0600 Received: from localhost.eng.sematech.org by thecount.eng.sematech.org (8.6.12/I-1.8) with SMTP id QAA10872; Tue, 5 Dec 1995 16:38:57 -0600 Message-Id: <199512052238.QAA10872@thecount.eng.sematech.org> X-Authentication-Warning: thecount.eng.sematech.org: Host localhost.eng.sematech.org didn't use HELO protocol To: Brent@greatcircle.com (Brent Chapman) cc: Quentin.Fennessy@sematech.org, Firewalls Mailing List Subject: Re: Fair use? of RFC1244 in "Internet Firewalls and Network Security" In-reply-to: Your message of "Tue, 05 Dec 1995 14:10:04 +0100." Date: Tue, 05 Dec 1995 16:38:55 -0600 From: "Quentin Fennessy" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >As much as I despise the New Riders book (as you said, it's largely a >cobbled-together knockoff of various publicly-available info), I'd point >out that RFC1244 (and the RFCs in general) are NOT copyrighted... So while >you and I may not like what they did, it was legal... I cannot tell who from the above attribution but someone made a good distinction - the RFCs in general and RFC1244 in particular are not copyrighted. So IFaNS did not break the law -- I thought the lack of attribution very sleazy though. Quentin From firewalls-owner Tue Dec 5 16:54:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA05488 for firewalls-outgoing; Tue, 5 Dec 1995 16:44:22 -0800 (PST) Received: from gatekeeper.alpharel.com (gatekeeper.ALPHAREL.COM [204.118.5.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id QAA05474 for ; Tue, 5 Dec 1995 16:44:12 -0800 (PST) Received: (from mail@localhost) by gatekeeper.alpharel.com (8.6.8/8.6.6a) id QAA19950; Tue, 5 Dec 1995 16:44:59 -0800 Received: from optigfx.optigfx.com(147.203.1.30) by gatekeeper.alpharel.com via smap (V1.5mrm) id sma019925; Tue Dec 5 16:44:21 1995 Received: from visalia.optigfx.com by optigfx.optigfx.com (4.1/SMI-4.1-3) id AA26273; Tue, 5 Dec 95 16:41:19 PST Received: (from mrm@localhost) by visalia.optigfx.com (8.6.9/8.6.9) id QAA17600; Tue, 5 Dec 1995 16:41:17 -0800 Date: Tue, 5 Dec 1995 16:41:17 -0800 From: Mike Murphy Message-Id: <199512060041.QAA17600@visalia.optigfx.com> To: smith@sctc.com Subject: Re: Firewall Selection Criteria Cc: firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >From smith@sctc.com Tue Dec 5 15:59:32 1995 >From: Rick Smith >Subject: Re: Firewall Selection Criteria >To: mrm@optigfx.com (Mike Murphy) >Date: Tue, 5 Dec 1995 17:23:19 -0600 (CST) >Cc: smith@sctc.com, firewalls-owners@GreatCircle.COM, mrm@sceard.com >In-Reply-To: <199512052012.MAA16962@visalia.optigfx.com> from "Mike Murphy" at Dec 5, 95 12:12:13 pm > >Mike Murphy asks: > >> Rather than the vendor providing "convincing evidence" and calling >> that "assurance", how's about the vendor providing a warranty with >> real teeth in it, say for example $1.25e6 US bonded indemnity if >> a verifiable breakin occurs. >> >> That would be assurance. "Convincing evidence" is marketing. >> Note that my statements above are argument by assertion. > >Warranties on cars work really well because you can dramatically >demonstrate when the car breaks. The problem with firewalls is that >they only represent one axis of attack. I'd love to have a way to >establish evidence that shows that an attack *did* or *did*not* go >through a firewall. > >In the absence of clear standards for this, it would sound like a >feeble marketing ploy. Any ideas of how to warrant firewalls? Cheap shot alert on :-) No more so a ploy than a "challenge" might be a feeble marketing ploy. Cheap shot alert off. Yes. I have a simple idea of how to warrant a firewall. "If the system(s) protected by this firewall is(are) entered in an unauthorized manner through the firewall, then Blort Industries will pay arbitrated damages in an amount not to exceed $1.25e6 US. Determination of unauthorized entry will be verified by court appointed arbitrator." This is a "put your money where your mouth is" warranty. I'll hold my breath until some vendor grants something similar. (Us too. :-) > >I suspect the situation is a bit more akin to what drug companies do. >You can't test a batch of pills before you take them; all you can do >is trust the drug company. They, in turn, provide "assurance" that >they do it right, including company sponsored R&D that demonstrates >the pills' effectiveness. They don't provide any guarantees, either. Actually, the drug companies do provide guarantees. If the drug has bad side effects or is ineffective, the drug company may be held liable. One drug, Thalidomide (sp?), comes immediately to mind. Big damages. I suppose I could mention what breast implants did for the manufacturer of the implants, too. BTW, the courts get to determine warranties for merchantability and fitness. Warranties may be found not to be limited by disclaimers of vendor. Determinations can take a long time. Just for grins, if I were spending a pile of money on a firewall from a vendor of unmatched reputation, I'd kind of like to know what product liability insurance they carry. If they didn't carry any, or if it wasn't sufficient, why, I just might consider their assurance to be less than weighty. Enough, this wanders. And I don' wanna hear the difference between guarantee and warranty. :-) > >Rick. >smith@sctc.com > -- Mike Murphy mrm@alpharel.com +1.619.625.3000 x265 ALPHAREL 9339 Carroll Park Drive San Diego, CA 92121 Any opinions above are mine and not those of my employer. From firewalls-owner Tue Dec 5 17:32:05 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id RAA06343 for firewalls-outgoing; Tue, 5 Dec 1995 17:02:19 -0800 (PST) Received: from copns1.ci.phoenix.az.us (copns1.ci.phoenix.az.us [148.167.202.131]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id RAA06336 for ; Tue, 5 Dec 1995 17:02:13 -0800 (PST) Received: from SOFTSW.CI.PHOENIX.AZ.US ([148.167.1.7]) by copns1.ci.phoenix.az.us (8.6.9/8.6.9) with SMTP id SAA27324 for ; Tue, 5 Dec 1995 18:03:32 -0700 Received: from CCMAIL1.CI.PHOENIX.AZ.US by SOFTSW.CI.PHOENIX.AZ.US (Soft*Switch Central V4L380P6) id 610900180095339FCCMAIL1; 05 Dec 1995 18:00:18 GMT Message-Id: Date: 05 Dec 1995 18:00:18 GMT From: "Dave Pristavec" Subject: SendMail - Hiding internal mail servers To: firewalls@GreatCircle.com Comment: MEMO 12/05/95 18:03:00 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I'm looking for some information/help with hiding my internal mail servers from the 'outside'. I'm currently running Berkeley version 8.3 sendmail on a Sun machine (Solaris 2.4) that also is my DNS. I inherited the Sendmail configuration form another system administrator and have been reading the 'SendMail' book by O'Reilly & Associates in trying to resolve my problem, but my progress has been slow. If anyone has some input on their experience in configuring Sendmail I would appreciate it. Here is an example of my current configuration file. Cwci.phoenix.az.us CXinternal mail server.ci.phoenix.az.us define ('MAIL_HUB', mail) LOCAL_RULE_1 R$- $@$1<@$R> special local case R$+<@$=X> $@$1<@$j> send user at domain I would appreciate any response either to here or CC mail me at DPRISTAV@ci.phoenix.az.us. Thanks.... ** Experience is gained 1 day at a time ** From firewalls-owner Tue Dec 5 17:54:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA03190 for firewalls-outgoing; Tue, 5 Dec 1995 15:58:08 -0800 (PST) Received: from wotan.compaq.com (wotan.compaq.com [131.168.249.254]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id PAA03184 for ; Tue, 5 Dec 1995 15:58:03 -0800 (PST) From: ESterling@bangate.compaq.com Received: from twisto.eng.hou.compaq.com(really [131.168.254.216]) by wotan.compaq.com via sendmail with smtp id for ; Tue, 5 Dec 95 17:24:55 -0600 (CST) (/\##/\ Smail3.1.30.13 #30.4 built 17-oct-95) Received: from bangate.compaq.com(really [131.168.114.234]) by twisto.eng.hou.compaq.com via sendmail with smtp id for ; Tue, 5 Dec 95 17:14:10 -0600 (CST) (/\##/\ Smail3.1.30.13 #30.3 built 13-oct-95) Received: by bangate.compaq.com; Tue, 5 Dec 95 17:14:04 CST Date: Tue, 5 Dec 95 17:12:44 CST Message-ID: X-Priority: 3 (Normal) To: Subject: RFC listing Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On what web page are the current RFC's listed? esterling@bangate@compaq.com From firewalls-owner Tue Dec 5 18:32:04 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA01742 for firewalls-outgoing; Tue, 5 Dec 1995 15:27:02 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id PAA01727 for ; Tue, 5 Dec 1995 15:26:53 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id RAA29309 for ; Tue, 5 Dec 1995 17:31:13 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id RAA29305 for ; Tue, 5 Dec 1995 17:31:13 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id RAA03361 for ; Tue, 5 Dec 1995 17:28:26 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id RAA15821 for firewalls@greatcircle.com; Tue, 5 Dec 1995 17:28:26 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id RAA03260 for ; Tue, 5 Dec 1995 17:23:21 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id RAA15755; Tue, 5 Dec 1995 17:23:20 -0600 From: Rick Smith Message-Id: <199512052323.RAA15755@shade.sctc.com> Subject: Re: Firewall Selection Criteria To: mrm@alpharel.com (Mike Murphy) Date: Tue, 5 Dec 1995 17:23:19 -0600 (CST) Cc: smith@sctc.com, firewalls-owners@greatcircle.com, mrm@sceard.com In-Reply-To: <199512052012.MAA16962@visalia.optigfx.com> from "Mike Murphy" at Dec 5, 95 12:12:13 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Mike Murphy asks: > Rather than the vendor providing "convincing evidence" and calling > that "assurance", how's about the vendor providing a warranty with > real teeth in it, say for example $1.25e6 US bonded indemnity if > a verifiable breakin occurs. > > That would be assurance. "Convincing evidence" is marketing. > Note that my statements above are argument by assertion. Warranties on cars work really well because you can dramatically demonstrate when the car breaks. The problem with firewalls is that they only represent one axis of attack. I'd love to have a way to establish evidence that shows that an attack *did* or *did*not* go through a firewall. In the absence of clear standards for this, it would sound like a feeble marketing ploy. Any ideas of how to warrant firewalls? I suspect the situation is a bit more akin to what drug companies do. You can't test a batch of pills before you take them; all you can do is trust the drug company. They, in turn, provide "assurance" that they do it right, including company sponsored R&D that demonstrates the pills' effectiveness. They don't provide any guarantees, either. Rick. smith@sctc.com From firewalls-owner Tue Dec 5 18:42:38 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA01840 for firewalls-outgoing; Tue, 5 Dec 1995 15:29:31 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id PAA01828 for ; Tue, 5 Dec 1995 15:29:23 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id QAA27950 for ; Tue, 5 Dec 1995 16:28:46 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id QAA27946 for ; Tue, 5 Dec 1995 16:28:46 -0600 Received: from mario.sctc.com (mario.sctc.com [172.17.192.177]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id QAA02567 for ; Tue, 5 Dec 1995 16:26:01 -0600 (CST) Received: (from dowd@localhost) by mario.sctc.com (8.6.12/8.6.9) id QAA06778; Tue, 5 Dec 1995 16:25:58 -0600 Date: Tue, 5 Dec 1995 16:25:57 -0600 (CST) From: Alan Dowd To: firewalls@greatcircle.com Subject: Re: Fair use? of RFC1244 in "Internet Firewalls and Network Security" In-Reply-To: <199512051730.LAA08157@thecount.eng.sematech.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Tue, 5 Dec 1995, Quentin Fennessy wrote: [...snip...] > This morning I worked on a network configuration problem. The problem > involved security considerations, so I decided to use two resources: > RFC1244 and a book I recently purchased, "Internet Firewalls and > Network Security" (IFaNS). > > Internet Firewalls and Network Security > Karanjit Siyan, PHD > Chris Hare > 1995 > New Riders Publishing > ISBN 1-56205-437-6 > > I recommend you _NOT_ buy this book! > [...snip...] > > Virtually all the useful information I found in > chapter 3 of IFaNS was originally published in RFC1244. I am very > disapointed in IFaNS. I have not read the rest of the book but now I > wonder at its originality. > > Quentin Fennessy > I, too, have reservations about this book, but I place them more with the editorial policies and staff at New Riders Publishing than with the author(s). The proof-reading and copy-editting were sloppy: some of the examples were out of order or directly contradicted the text; the reference for TIS's Firewall Toolkit mailing list was out of date (forgivable in the dynamic Internet environment), but the info provided was in error even when it was in date. The example you cite was just one of many provided to bulk out the book to justify its price; what earthly good is five pages of Toolkit packing list? (BTW: Marcus, did you get royalties for your contributions on pp. 358-359?) The material is repetative from chapter to chapter as well. The implementation discussions in chapter 8 focus too much on the details of specific vendor products and not enough on the general characteristics of the various classes of tools. Having said all that, I must also say that the material in Chapters 5 and 7 was very useful to me in explaining filtering and firewalling concepts to a client, particularly the stack-oriented diagrams in Chapter 7. Overall, I think the book is overpriced and bloated, but it does contain some material that can be reworked usefully (sauce for the goose ...). Regards, Al Dowd From firewalls-owner Tue Dec 5 19:56:01 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id TAA13178 for firewalls-outgoing; Tue, 5 Dec 1995 19:44:33 -0800 (PST) Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id TAA13169 for ; Tue, 5 Dec 1995 19:44:28 -0800 (PST) Received: from beach.sctc.com by relay3.UU.NET with SMTP id QQzsve07952; Tue, 5 Dec 1995 12:34:06 -0500 (EST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id LAA18638; Tue, 5 Dec 1995 11:36:25 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id LAA18634; Tue, 5 Dec 1995 11:36:22 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id LAA26637; Tue, 5 Dec 1995 11:33:42 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id LAA07829; Tue, 5 Dec 1995 11:33:42 -0600 Date: Tue, 5 Dec 1995 11:33:42 -0600 From: Rick Smith Message-Id: <199512051733.LAA07829@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, leonard@geminisecure.com Subject: Firewalls on MLS Systems (was: chroot) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I alluded to the problems of building a firewall on an MLS system during our marathon chroot() discussion: >> Another problem, which is held by most alternatives that Marcus >> noted in recent posts, is that correct behavior is in the hands >> of the applications software. If the applications software goofs, >> the protections are GONE. The underlying OS, whether it's a homespun >> Unix kernel or a TCSEC evaluated platform, can't step in and help. and Leonard Miyata replied: >I would have to differ on the above statement. >For those who don't know about Multi-Levl operating systems, a >application for a "TRUSTED OS" is divided up into different modules with >different levels of Security and integrity. The most common security >model used from inter-process communications is that a 'Higher' level >subject can 'Read Up' and 'Write Down' to a lower level subject, but the >opposite is (with special exceptions) not allowed. This is enforced by >multi-level Kernal and the CPU protected mode ring structure. > >The only exception to this is with 'Trusted Subjects' which >1. Require special Kernal Calls. >2. Can only be installed and configured in a off-line process. >3. Should be minimal for Trust and Verification. This is indeed the textbook MLS Trusted Systems answer. But like all textbook answers, it reads better than it performs. In our own experience, we've noted the following about this particular approach: 1) There are only three domains: one each for the two environments that communicate, and a "trusted" environment to handle all data flow between the two. 2) Given that a firewall consists of nothing but software to mediate data flow between an inside and an outside networking domain, this places *ALL* of the firewall software in that one "trusted" domain. This conflicts with requirement #3 of trusted subjects above unless you limit the firewall to very basic capabilities. 3) If someone does manage to penetrate a piece of "trusted" application software (not impossible given the amount in a full function firewall) they can bypass the platform enforced permissions. In any case, a prudent analyst takes this risk into account. 4) There's nothing in the standard model to prevent an attacker from installing subverted software once an application has been penetrated. 5) Given that all networking software for a given network needs to reside in the same protection domain, the system can't prevent one application from attacking another. 6) Those "read up" and "write down" rules are an awkward thing to use to construct the access paths an firewall needs. I've seen one or two writeups on how to do it. But you have to fit the software to the mechanism instead of vice versa. That's more risky, and limits the the ways you can transfer information between domains. We developed the Type Enforcement concept to counter these problems. It was originally built into a conventional Orange Book TCB. Type Enforcement applies more directly to commercial applications than conventional MLS controls, so we dropped the MLS stuff and put TE into Sidewinder by itself. Rick. smith@sctc.com secure computing corporation From firewalls-owner Tue Dec 5 20:24:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA14294 for firewalls-outgoing; Tue, 5 Dec 1995 20:07:53 -0800 (PST) Received: from denver.ssds.com (denver.ssds.com [134.127.16.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id UAA14288 for ; Tue, 5 Dec 1995 20:07:48 -0800 (PST) Received: from freke.ssds.com (rem_den29.ssds.com [134.127.122.29]) by denver.ssds.com (8.6.9/8.6.9.SSDSnet-hub) with SMTP id VAA02861; Tue, 5 Dec 1995 21:08:20 -0700 Message-Id: <2.2b8.32.19951206040625.0075e3c4@denver.ssds.com> X-Sender: cds@denver.ssds.com X-Mailer: Windows Eudora Pro Version 2.2b8 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Dec 1995 22:06:25 -0600 To: Rick Smith From: "Chris Liljenstolpe (Swanson) - SSDS" Subject: Re: Firewalls for the rest of us (was Re: A1 Systems) Cc: firewalls@GreatCircle.COM, smith@sctc.com, anton@the-wire.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Greetings, Actually, I see this system being adequately reflected in a two-dimensional graph. The Y-axis is cost and the X-axis is level of security. One curve is the level of security vs. the cost of that security (this includes actual costs, difficulty of use/unavailability of resources/information, etc.). The second curve is the cost of exposure vs. level of security. This curve measures the potential cost to an organization if an exposure is exploited (and amortizes it for probability of exploitation). Both of these curves are asymptotic. Where they cross is the minimum point, and therefore where total costs are at the minimum. Regards, -=Chris is At 14:37 95/12/05 -0600, the sage, Rick Smith, uttered these words: (>Anton J Aylward writes about trading cost of loss (>against cost of security: (> (>> Visualize a graph if you will, two curves: A/x and B-(C/x) One curve (>> is the value of what you want to protect, the other is what you are (>> spending on protecting. You're plotting cost of security vs exposure. (>> Somewhere the curves cross, your cost of righ and your cost of (>> protection are in balance. (> (>Just to share a different point of view, I find it impossible to talk (>intelligently about only two axes. You need a third axis which shows (>operational needs/capabilities. (> (>The best analogy is physical security. You can always put your (>valuables in a box and embed it in a thick covering of concrete. This (>produces strong certainty regarding the physical location of your (>valuables but reduces their usability. Once you put a door in the box (>you're trading accessability against risk of loss. At the far end you (>have a store open to the public -- yes, you get ripped off regularly, (>but you treat it as a cost of doing business. The "security measures" (>you take are activities that minimize losses and recoup their costs. (>The tradeoff isn't risk against security costs, it's both against (>operational needs. (> (>After the Gulf War the defense establishment here decided they (>couldn't wait for trusted OSes on everyones' desktop before hooking (>Internet e-mail to classified network. They decided the risk of (>desktop subversion was acceptable in exchange for the benefits of (>network connectivity. So, they increased their exposure to attack at (>the same time the threat was growing. They traded off the increased (>risks against increased operational capabilities. Clausewitz could (>have predicted it. (> (>Rick. (>smith@sctc.com secure computing corporation (> (> -- ( ( | ( Chris Liljenstolpe ) ) (| ), inc. SSDS, Inc; 8400 Normandale Lake Blvd.; Suite 993 business driven Bloomington, MN 55437; technology solutions TEL 612.921.2392 FAX 612.921.2395 Um Yah Yah! From firewalls-owner Tue Dec 5 21:54:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA17344 for firewalls-outgoing; Tue, 5 Dec 1995 21:32:00 -0800 (PST) Received: from uuneo.neosoft.com (uuneo.neosoft.com [206.109.1.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id VAA17331 for ; Tue, 5 Dec 1995 21:31:54 -0800 (PST) Received: from ris1.UUCP (ficc@localhost) by uuneo.neosoft.com (8.7.3/8.7.1) with UUCP id SAA04068 for GreatCircle.COM!firewalls; Tue, 5 Dec 1995 18:39:44 -0600 (CST) Received: by ris1.nmti.com (smail2.5) id AA28479; 5 Dec 95 18:49:48 CST (Tue) Received: by sonic.nmti.com; id AA21767; Tue, 5 Dec 1995 18:19:50 -0600 From: peter@nmti.com (Peter da Silva) Message-Id: <9512060019.AA21767@sonic.nmti.com.nmti.com> Subject: Re: chroot/setuid vs type enforcement To: smith@sctc.com (Rick Smith) Date: Tue, 5 Dec 1995 18:19:50 -0600 (CST) Cc: anton@the-wire.com, smith@sctc.com, firewalls@GreatCircle.COM In-Reply-To: <199512051645.KAA06388@shade.sctc.com> from "Rick Smith" at Dec 5, 95 10:45:53 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > >I blame the early people at Berkeley for a lot. Like Peter da Silva > >points out, having the network calls bypass the convention of the file > >system devices is a case in point. > I have a hard time finding fault with a development team when they've > failed to solve a problem they didn't design for. First, I don't believe that CSRG was negligent in not considering security. They *did* consider it, and put in a number of hacks to enforce it. And as you say, it was a learning experience. So I agree that the term 'blame' is misplaced. Still, the whole model of exposing a new namespace to applications to do networking is flawed. Prior to BSD networking and System V IPC, it was assumed that all storage and communication objects visible to a program were in the file system and subject to the filesystem's security... > I believe that an explicit, formal security model is the only thing > that might have kept Unix from diverging so dramatically. It *did* have one. It was ignored. > To be honest, aren't we really discussing a security model for Unix > that's been extracted in retrospect? Nope. It was pretty obvious to me at UCB in 1980. I believe that CSRG understood it too... after all I was just a freshman, they were grad students. They just assumed that the low number port hack would be good enough, they were running short on time, so they chose not to follow it. In any case, why don't you ask them if you think I'm out of order? They're almost all still on the net... point your mailers at BSDI... From firewalls-owner Wed Dec 6 00:24:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id AAA21273 for firewalls-outgoing; Wed, 6 Dec 1995 00:05:49 -0800 (PST) Received: from NUki (nuki.netuse.de [193.98.110.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id AAA21268 for ; Wed, 6 Dec 1995 00:05:42 -0800 (PST) Received: by Mail.NetUSE.de (SMail3.1.28.1 #2) ID m0tNEZ0-0009AoC: Wed, 6 Dec 95 08:46 MET Received: by white.schulung.netuse.de (Smail3.1.29.0 #2) id m0tNDXK-0008vCC; Wed, 6 Dec 95 07:41 MET Received: from GATEWAY by white.schulung.netuse.de with netnews for firewalls@greatcircle.com (firewalls@greatcircle.com) To: firewalls@greatcircle.com Date: Wed, 6 Dec 1995 06:34:44 GMT From: kris@schulung.netuse.de (=?ISO-8859-1?Q?Kristian_K=F6hntopp?=) Message-ID: Organization: =?ISO-8859-1?Q?entf=E4llt?= References: <199512051548.HAA16511@miles.greatcircle.com> Subject: Re: Small Demo scanner required. Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Firewalls@GreatCircle.COM writes: >in advance. Putting up some slides or results of a scanner/security >tool can be pretty cool if it's the machine of the person hosting the >talk or something (assuming you have the ok, 'natch), or merely some ^^^^^^^^^^^^^^^^^^^^^^^^ >simple stats. And this reminder should not be necessary, but *please* *do* *get* *permission* to do so. You all remember what happened to Randal Schwartz, don't you? Kristian -- Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897 "Z-Netz? Who the fuck is Z-Netz?" -- jop@informatik.uni-kiel.d400.de (Joerg Pechau) in d.t.b From firewalls-owner Wed Dec 6 00:54:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id AAA21882 for firewalls-outgoing; Wed, 6 Dec 1995 00:51:59 -0800 (PST) Received: from mail.eskimo.com (mail.eskimo.com [204.122.16.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id AAA21877 for ; Wed, 6 Dec 1995 00:51:55 -0800 (PST) From: nokie@eskimo.com Received: from 10.0.2.15 (nokie@tia1.eskimo.com [204.122.16.40]) by mail.eskimo.com (8.6.12/8.6.12) with SMTP id AAA07750 for ; Wed, 6 Dec 1995 00:52:36 -0800 Date: Wed, 6 Dec 1995 00:52:36 -0800 Message-Id: <199512060852.AAA07750@mail.eskimo.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Staffing Requirements To: firewalls@GreatCircle.COM X-Mailer: SPRY Mail Version: 04.00.06.14 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk One of the divisions of the company I work for has a permanent connection to the Internet secured by a Tis Toolkit and a Livingston router doing packet filtering. Since the connection at this division is of limited bandwidth (56k at present), over the past year or so some 40 to 50 individuals around the company (nationwide, but primarily at our central location) have obtained individual accounts with local ISPs in order to get access. These users are primarily using Spry's Internet in a Box, but there are also some NT users, OS/2 users, and a couple of Unix machines as well. Since this growth has not been managed centrally, and we have (also in the last year or so) finished building a private internet connecting most of our domestic sites, we are concerned about the risks that these unsecured dial-up connections pose. Within the month, the division with the permanent connection will be upgrading to a T1 which we feel is adequate to meet the needs of the corporation for Internet access. We plan to move the serial users to connecting via their lan connections using the bandwidth and the firewall at the division with the permanent connection. My boss (actually my bosses bosses boss, but who's counting) has asked me to determine the staffing requirements for maintaining and monitoring the firewall. Our tendency has been to add function without adding headcount; the techs that are involved in this project feel that this is not an occasion where that is practical due to the amount of time and effort involved in monitoring logs, etc. What is the general consensus on the amount of time and effort involved in these tasks? David Nichols -- on my own dime! From firewalls-owner Wed Dec 6 01:24:17 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id BAA22679 for firewalls-outgoing; Wed, 6 Dec 1995 01:17:14 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id BAA22674 for ; Wed, 6 Dec 1995 01:17:05 -0800 (PST) Message-Id: <199512060917.BAA22674@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA042761401; Wed, 6 Dec 1995 20:16:41 +1100 From: Darren Reed Subject: Re: FW: chroot/setuid vs type enforcement To: daemeonr%Anthros.Com@Anthros.Com Date: Wed, 6 Dec 1995 20:16:41 +1100 (EDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9512051650.AA01139@phoebe.Anthros.Com> from "daemeonr%Anthros.Com@Anthros.Com" at Dec 5, 95 08:50:04 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In some mail from daemeonr%Anthros.Com@Anthros.Com, sie said: > > Recently, Darren Reed wrote: [...] > => A digression... > => > => It doesn't take imagination to look at a function or system call, the > => parameters it takes, and extremes of input. This is part of formal > => design/testing for software; or so I thought. > > It does take (a) time, (b) knowledge that you need to look at (code for) > boundary conditions, and (c) motivation. > > (a) assumes a reasonable development cycle > (b) assumes experience > (c) assumes experience > > (a) assumes competent management which pays for experience and allows for > development costs. Lacking (a), you demotivate people to use (b) and (c). > > Get real you guys. A competent manager is perceived as such by his managers > or he wouldn't get hired. How many upper managers are technically concerned > let alone competent? Mostly they are skilled at convincing a customer to > part with their money (hence the success of HP in the market place vis a vis > Sun; hence the success of Oracle vis a vis Sybase; Hence ... ) Sorry, I missed the relevance of this to the above. Are you trying to say that managers write code ? Or that managers who have no knowledge of technical skills are put in charge of technical projects which are allowed to proceed ? [...] > I am working on a piece of OSF code that has *sigificant* problems with a lack > of boundary conditions testing - and it represents a MAJOR change to the way > security is/will be done on UNIX. The porting is done, the remaining weeks are > to fix the boundary problems. How many of YOUR managers would slip a major > OS release to fix the problems? Fortunately mine will (this time). [...] Well, if you're working on OSF, and the above describes managers at DEC then it's little wonder that Ultrix has had the problems it has/does, and scares me when it comes to OSF (how did VMS get lucky ?!) If the code you're working on is lacking relevant checks, what does it say for the security portion ? Also, in general, it is nice to not have a program core dump just because you cut-and-paste and entire window in the input buffer, accidently. Please, feel free to correct me, I didn't understand the point of your mail much except to point the blame at managers for bad code. darren From firewalls-owner Wed Dec 6 02:28:19 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id BAA23582 for firewalls-outgoing; Wed, 6 Dec 1995 01:59:55 -0800 (PST) Received: from giasbm01.vsnl.net.in ([202.54.1.18]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id BAA23577 for ; Wed, 6 Dec 1995 01:59:44 -0800 (PST) Received: by giasbm01.vsnl.net.in; (5.65v3.2/1.1.8.2/31Jul95-0643PM) id AA03472; Wed, 6 Dec 1995 15:30:20 GMT Date: Wed, 6 Dec 1995 15:30:20 +0000 (GMT) From: "Mr.Sunay Gandhi" To: ESterling@bangate.compaq.com Cc: firewalls@greatcircle.com Subject: Re: RFC listing In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Tue, 5 Dec 1995 ESterling@bangate.compaq.com wrote: > On what web page are the current RFC's listed? > > esterling@bangate@compaq.com > Most Probably on ds.internic.net. or just www.internic.net CYA Sunay From firewalls-owner Wed Dec 6 03:24:18 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id DAA25949 for firewalls-outgoing; Wed, 6 Dec 1995 03:03:39 -0800 (PST) Received: from gate.ggr.co.uk ([193.128.25.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id DAA25944 for ; Wed, 6 Dec 1995 03:03:32 -0800 (PST) Received: from mailhub.ggr.co.uk (uk0x07.ggr.co.uk) by gate.ggr.co.uk; Wed, 6 Dec 1995 11:02:35 GMT Received: from ukwit01.ggr.co.uk (ukwit01.ggr.co.uk) by mailhub.ggr.co.uk; Wed, 6 Dec 1995 10:59:22 GMT Received: by ukwit01.ggr.co.uk (8.7.1/imd160294) id LAA01524; Wed, 6 Dec 1995 11:04:53 GMT From: "Lack Mr G M" Message-Id: <9512061104.ZM1522@ukwit01> Date: Wed, 6 Dec 1995 11:04:53 +0000 In-Reply-To: "Johnson-Bryden, Ian" "RE: Napoleon and Clausewitz" (Dec 5, 6:13pm) References: <30C49027@smtpgty.saicuk.co.uk> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "'firewalls@greatcircle.com'" Subject: Re: Napoleon and Clausewitz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Dec 5, 6:13pm, Johnson-Bryden, Ian wrote: >... > In the same way I doubt that Napoleon equipped his > troops with stones because guns were designed by theoreticians who > calculated the weight of shot, the chamber pressure, the angle of elevation, > etc., and the resulting product cost real money but the stones were just > laying about and cost nothing. However some people do choose to use the > stones of firewalling to avoid spending money. If it works for them good > luck to them but if it does not then they only have themselves to blame. The people for whom it works are those who see these stones for what they really are - precious ore - and have the skills to smelt them and fashion the resulting metals into works of art. -- ----------- Gordon Lack ----------------- gml4410@ggr.co.uk ------------ The contents of this message *may* reflect my personal opinion. They are *not* intended to reflect those of my employer, or anyone else. From firewalls-owner Wed Dec 6 03:55:59 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA25837 for firewalls-outgoing; Wed, 6 Dec 1995 02:59:05 -0800 (PST) Received: from neon.ingenia.com (neon.ingenia.com [205.207.219.29]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id CAA25832 for ; Wed, 6 Dec 1995 02:58:59 -0800 (PST) Received: (from shaver@localhost) by neon.ingenia.com (8.6.12/8.6.9) id GAA22937; Wed, 6 Dec 1995 06:00:12 -0500 From: Mike Shaver Message-Id: <199512061100.GAA22937@neon.ingenia.com> Subject: Re: selection criteria? To: mjr@iwi.com Date: Wed, 6 Dec 1995 06:00:12 -0500 (EST) Cc: firewalls@GreatCircle.COM In-Reply-To: <199512020409.XAA14695@switchblade.iwi.com> from "Marcus J. Ranum" at Dec 1, 95 11:09:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Thus spake Marcus J. Ranum: > I played a naughty little game at a conference recently > where I polled the room by show-of-hands as to what were the > important things they looked for in firewalls. Features, price, > and vendor reputation were pretty much the top categories. I'd > cheated and left "security" off my list and I thought I was going > to get away with it until someone flagged me when I asked "are > there any criteria I forgot to put on the list...?" I'm beginning to feel a little lonely, but am I _really_ the only one who sees security as a feature? In my mind, a feature is "something it does". Whether that's provide a point-and-drool puncture apparatus for the packet filtering (mjr-esque "feature") or provide a bulletproof defense against IP spoofing (mjr-esque "security") matters not. Mike (completely secure that, if he is in fact the only one, he will soon find out why ;) ) -- #> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation <# #> Technical Specialist -- will tame sendmail(8) for food <# #> <# #> "You are a very perverse individual, and I think I'd like to get to <# #> know you better." --- eric@reference.com <# From firewalls-owner Wed Dec 6 04:54:18 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id EAA28633 for firewalls-outgoing; Wed, 6 Dec 1995 04:36:11 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.235.77]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id EAA28616 for ; Wed, 6 Dec 1995 04:36:06 -0800 (PST) Received: from pferguso-pc.cisco.com (c1robo10.cisco.com [171.68.13.20]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id EAA15899; Wed, 6 Dec 1995 04:36:45 -0800 Message-Id: <199512061236.EAA15899@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Dec 1995 07:37:02 -0500 To: ESterling@bangate.compaq.com From: Paul Ferguson Subject: Re: RFC listing Cc: Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Try ftp://ds.internic.net/rfc - paul At 05:12 PM 12/5/95 CST, ESterling@bangate.compaq.com wrote: >On what web page are the current RFC's listed? > > esterling@bangate@compaq.com > > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso@cisco.com c i s c o S y s t e m s From firewalls-owner Wed Dec 6 05:24:18 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id EAA28990 for firewalls-outgoing; Wed, 6 Dec 1995 04:49:16 -0800 (PST) Received: from frege.math.ethz.ch (frege-hg.math.ethz.ch [129.132.104.6]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id EAA28985 for ; Wed, 6 Dec 1995 04:49:06 -0800 (PST) From: saouli@math.ethz.ch Received: from panoramix.ethz.ch (saouli@panoramix.ethz.ch [129.132.104.35]) by frege.math.ethz.ch (8.6.4/Main-mathdept-mailer) with ESMTP id NAA06673; Wed, 6 Dec 1995 13:49:27 +0100 Received: (saouli@localhost) by panoramix.ethz.ch (8.6.9/D-MATH-client) id NAA16386; Wed, 6 Dec 1995 13:49:26 +0100 Message-Id: <199512061249.NAA16386@panoramix.ethz.ch> Subject: Re: selection criteria? To: shaver@neon.ingenia.com (Mike Shaver) Date: Wed, 6 Dec 1995 13:49:26 +0100 (MET) Cc: mjr@iwi.com, firewalls@GreatCircle.COM In-Reply-To: <199512061100.GAA22937@neon.ingenia.com> from "Mike Shaver" at Dec 6, 95 06:00:12 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > > Thus spake Marcus J. Ranum: > > I played a naughty little game at a conference recently > > where I polled the room by show-of-hands as to what were the > > important things they looked for in firewalls. Features, price, > > and vendor reputation were pretty much the top categories. I'd > > cheated and left "security" off my list and I thought I was going > > to get away with it until someone flagged me when I asked "are > > there any criteria I forgot to put on the list...?" > > I'm beginning to feel a little lonely, but am I _really_ the only one > who sees security as a feature? In my mind, a feature is "something > it does". Whether that's provide a point-and-drool puncture apparatus > for the packet filtering (mjr-esque "feature") or provide a > bulletproof defense against IP spoofing (mjr-esque "security") matters > not. Is availability of resources a feature to your users? Is privacy (or at least some art of confidentiality) a feature to your users? If you answer to those 2 questions by yes, then you might want to scrap every kind of "security" your organisation has, beginning with door locks. If you answer no to at least one of the two questions above then you might want to consider security more then just a feature. > > Mike > (completely secure that, if he is in fact the only one, he will soon > find out why ;) ) Enjoy your day :) -- Karim Saouli Math Department of the Network 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-632-1085 For pgp public key: finger saouli@gatekeeper.math.ethz.ch Key fingerprint: 3D B9 5A 01 A1 2A 0E E5 1E C9 02 C6 B8 D7 62 91 From firewalls-owner Wed Dec 6 05:59:28 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA29328 for firewalls-outgoing; Wed, 6 Dec 1995 05:07:23 -0800 (PST) Received: from neon.ingenia.com (neon.ingenia.com [205.207.219.29]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id FAA29323 for ; Wed, 6 Dec 1995 05:07:18 -0800 (PST) Received: (from shaver@localhost) by neon.ingenia.com (8.6.12/8.6.9) id IAA23228; Wed, 6 Dec 1995 08:08:12 -0500 From: Mike Shaver Message-Id: <199512061308.IAA23228@neon.ingenia.com> Subject: Re: selection criteria? To: saouli@math.ethz.ch Date: Wed, 6 Dec 1995 08:08:11 -0500 (EST) Cc: mjr@iwi.com, firewalls@GreatCircle.COM In-Reply-To: <199512061249.NAA16386@panoramix.ethz.ch> from "saouli@math.ethz.ch" at Dec 6, 95 01:49:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Thus spake saouli@math.ethz.ch: > Is availability of resources a feature to your users? Is privacy (or at least > some art of confidentiality) a feature to your users? > If you answer to those 2 questions by yes, then you might want to scrap > every kind of "security" your organisation has, beginning with door locks. I'll admit that you lost me there. We aren't talking about users' preferences here, we're talking about selection criteria for a security apparatus. If you've got your users defining the purchasing requirements for a firewall, then I think you've already sacrificed a significant part of whatever security you might have hoped to achieve. > If you answer no to at least one of the two questions above then you might > want to consider security more then just a feature. I suspect you're still defining feature as "thing the product does that doesn't include securing the network and/or itself". I'm lumping the mechanisms by which it provides security in with the mechanisms by which it allows you to control it, for example. What's the really fundamental difference between having nice, automated log processing and being able to deal with fragments properly? I'm saying there shouldn't be a difference, aside from the prioritization which occurs between all features. (I really don't know what you're saying. =) ) Being able to hand-edit the configuration data is more important to me than being able to see a pretty graph of traffic. Similarly, being able to stop address spoofing is more important to me than being able to detect stealth scans. What's wrong with also saying that the hand-editing ranks between the spoofing and the scan detection? Is integrated S/Key a feature? Or is it "security"? What are the defining characteristics of a feature, and how do they contrast the defining characteristics of "security"? If some aspect of the product makes it easier for me to do my job and track the data associated with the perimeter, it helps me keep on top of things, and that helps security. Does it help security more than Type Enforcement? More than a larger key for the encrypted administrative connections? If so, is it "security"? If not, is it a "feature"? Mike -- #> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation <# #> Ignore the man behind the curtain. <# #> <# #> "And then I realized that it never should have worked in the first <# #> place. Thus, it would not work again until rewritten." --- Anon. <# From firewalls-owner Wed Dec 6 06:31:55 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA01129 for firewalls-outgoing; Wed, 6 Dec 1995 05:55:40 -0800 (PST) Received: from hatteras.ch.inri.com (hatteras.ch.inri.com [198.202.184.13]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id FAA01123 for ; Wed, 6 Dec 1995 05:55:34 -0800 (PST) Received: from assateague (assateague.ch.inri.com [198.202.184.111]) by hatteras.ch.inri.com (8.6.12/8.6.6) with SMTP id IAA12150; Wed, 6 Dec 1995 08:58:53 -0500 Date: Wed, 6 Dec 1995 08:58:53 -0500 Message-Id: <199512061358.IAA12150@hatteras.ch.inri.com> X-Sender: wlb@hatteras.ch.inri.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Lehrer, Neil" , firewalls@GreatCircle.COM From: wbunting@ch.inri.com (Bill Bunting) Subject: Re: tis and udp Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 01:42 PM 12/5/95 -0500, Lehrer, Neil wrote: >hi, > >how does tis control udp connections? > >every time i see a review of a firewall there is controversy over this >subject. > UDP (User Datagram Protocol) is a connectionless protocol. This is why it is difficult for firewalls to deal with UDP. UDP is controversial because there is not a simple straight forward way to securely permit it. With TCP, you must establish a connection; therefore, it is easy to add strong authentication (proxies are easy to write). With UDP, there is no session -- each UDP packet is independent and delivery is not reliable. If a UDP packet takes a hit or is lost, that's life. see www.tis.com for information on how TIS implements UDP Firewall services. --------------------------------------- | Bill Bunting, Software Engineer | ****** |Inter-National Research Institute, Inc.| ***_******_ __ _ | 1441 Crossways Boulevard, Suite 102 | ===//=/\**//=/- )==//= | Chesapeake, Virginia 23320 | {==//=//\\//=//||==//== | V(804)424-8675 F(804)420-4262 | =//=//==\/*//=||=//=== | (wbunting@inri.com) | ********* | (bunting@cs.odu.edu) | ***** | http://www.cs.odu.edu/~bunting | --------------------------------------- From firewalls-owner Wed Dec 6 07:24:18 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA04105 for firewalls-outgoing; Wed, 6 Dec 1995 07:21:26 -0800 (PST) Received: from netcom.netcom.com (netcom.netcom.com [192.100.81.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA04099 for ; Wed, 6 Dec 1995 07:21:22 -0800 (PST) Received: by netcom.netcom.com (8.6.12/Netcom) id HAA14499; Wed, 6 Dec 1995 07:20:31 -0800 Date: Wed, 6 Dec 1995 07:20:30 -0800 (PST) From: Bob Bosen Subject: Re: SDI's Time-Synched SecurIDs To: Greg Woods cc: firewalls@greatcircle.com In-Reply-To: <199512041713.KAA21334@ncar.ucar.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Mon, 4 Dec 1995, Greg Woods wrote: [snip] > (as it happens, > we needed SDI because at present they are the only product that will > work with TACACS on Cisco routers since the current version of TACACS > won't support challenge/response; I understand Cisco is planning to > support TACACS+ with C/R; I can't wait). > > --Greg > Greg: Enigma Logic's "SafeWord Authentication Server" now supports TACACS+, and a free trial version can be obtained immediately from our www server. See the announcement on this subject in a prominent location near the middle of our primary web page: http://www.safeword.com Several challenge/response authenticators are supported, as are several synchronous devices, from a half dozen different vendors. Regards, Bob Bosen Enigma Logic Inc. 2151 Salvio St. #301 Concord, CA 94520 USA Tel: +1 510 827-5707 Internet: bbosen@netcom.com http://www.safeword.com ftp://ftp.safeword.com/download/ ************************************************************************** * "It wasn't me!!! Somebody must have captured my username/password!!!" * ************************************************************************** From firewalls-owner Wed Dec 6 07:54:18 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA04182 for firewalls-outgoing; Wed, 6 Dec 1995 07:23:20 -0800 (PST) Received: from services ([168.166.0.67]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA04177 for ; Wed, 6 Dec 1995 07:23:16 -0800 (PST) Received: from services by services (SMI-8.6/SMI-SVR4) id JAA03452; Wed, 6 Dec 1995 09:26:17 -0600 Date: Wed, 6 Dec 1995 09:26:15 -0600 (CST) From: "Frank K. Senter" X-Sender: fsenter@services To: firewalls@greatcircle.com Subject: Re: FW: Windows NT holes and Lotus Notes holes (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On an almost related topic: I have observed a pair of OS/2 Warp Connect machines that have decided their role in life is to be one-port routers. When they see all-F's broadcasts at the DLC layer (Token Ring), they forward those packets to the MAC address of their assigned default router. These broadcast messages are DNS queries and TCPBEUI junk bleeding across a filtering bridge from a (probably misconfigured) machine in another enterprise. I also see OSPF Hello's entering our LAN, but the PC's ignore these. Ok, gimme' a fire extinguisher, cause I'm 'bout to be flamed for decisions I didn't make. What are the security implications for a one-way broadcast hole? I think this hole is available for protocols other than IP. Seems there would be a justification for an application level gateway between us and our brotherly enterprise based on network management alone....wonder how many token ring sites use segment numbers 001 & 002? 8-) Yeah,yeah..shoulda' built ethernet....now hand me that fire bottle! Frank Senter Senior Information Specialist Missouri Highway and Transportation Department P.O. Box 270 Jefferson City MO 65102 > > John O'Sullivan wrote: > > I have yet to see an NT server that can be completely shut down for services. I've tried shutting off files sharing, domain services, etc. and still can't get the !@#$% thing to stop broadcasting services on ports 137 & 138. If anyone has had luck with this, I would love to hear how. > > From firewalls-owner Wed Dec 6 08:24:18 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA04531 for firewalls-outgoing; Wed, 6 Dec 1995 07:39:47 -0800 (PST) Received: from galil.austnsc.tandem.com (argyle.mpd.tandem.com [131.124.250.13]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id HAA04526 for ; Wed, 6 Dec 1995 07:39:43 -0800 (PST) Received: (from dreschs@localhost) by galil.austnsc.tandem.com (8.7.1/8.7.1) id JAA14918; Wed, 6 Dec 1995 09:42:38 -0600 (CST) To: Subject: Re: Firewall Selection Criteria References: <199512060041.QAA17600@visalia.optigfx.com> From: dreschs@mpd.tandem.com (Sten Drescher) Date: 06 Dec 1995 09:42:34 -0600 In-Reply-To: Mike Murphy's message of Tue, 5 Dec 1995 16:41:17 -0800 Message-ID: <5568fumc5x.fsf@galil.austnsc.tandem.com> Organization: Tandem Computers Lines: 26 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Mike Murphy said: MM> Yes. I have a simple idea of how to warrant a firewall. MM> "If the system(s) protected by this firewall is(are) entered in an MM> unauthorized manner through the firewall, then Blort Industries will MM> pay arbitrated damages in an amount not to exceed $1.25e6 MM> US. Determination of unauthorized entry will be verified by court MM> appointed arbitrator." MM> This is a "put your money where your mouth is" warranty. I'll hold MM> my breath until some vendor grants something similar. (Us too. :-) And what if the intrusion was because the customer misconfigured the firewall? How many levels of "Are you REALLY certain you want to do this?" are enough for the vendor to say "Sorry, it's your fault."? The only type of vendor who could give a warranty like this is one who says "We sell you the firewall, we install the firewall, we configure the firewall, we manage the firewall, you pay use $$$ all the time, and you never lay a finger on the firewall.". -- #include /* Sten Drescher */ To get my PGP public key, send me email with your public key and Subject: PGP key exchange Key fingerprint = 90 5F 1D FD A6 7C 84 5E A9 D3 90 16 B2 44 C4 F3 From firewalls-owner Wed Dec 6 09:10:45 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA06461 for firewalls-outgoing; Wed, 6 Dec 1995 08:37:47 -0800 (PST) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA06456 for ; Wed, 6 Dec 1995 08:37:42 -0800 (PST) Received: from beyond.clubfed.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.sgi.com:firewalls@GreatCircle.com> id IAA12304; Wed, 6 Dec 1995 08:38:38 -0800 Received: from aussie.clubfed.sgi.com by beyond.clubfed.sgi.com via ESMTP (950511.SGI.8.6.12.PATCH526/911001.SGI) for <@beyond.clubfed.sgi.com:firewalls@GreatCircle.com> id LAA03030; Wed, 6 Dec 1995 11:30:56 -0500 Received: (from andya@localhost) by aussie.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA02500 for firewalls@GreatCircle.com; Wed, 6 Dec 1995 08:30:54 -0800 From: "Andy Andrews" Message-Id: <9512060830.ZM2498@aussie.clubfed.sgi.com> Date: Wed, 6 Dec 1995 08:30:54 -0800 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: firewalls@GreatCircle.com Subject: How do I remove myself from this list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hi, Sorry to post this here, but how do I remove myself from this list ? Also, is there an equivalent newsgroup I can look at ? Thanks -- Come to the edge, He said. They said, we are afraid. Come to the edge, He said. They came. He pushed them ... and they flew. --Guillaume Apollinaire Andy Andrews andya@sgi.com From firewalls-owner Wed Dec 6 10:01:37 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA07079 for firewalls-outgoing; Wed, 6 Dec 1995 09:01:11 -0800 (PST) Received: from omega.IntraNet.com (omega.IntraNet.com [192.148.106.20]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA07074 for ; Wed, 6 Dec 1995 09:01:06 -0800 (PST) Received: by omega.IntraNet.com; (5.65/1.1.8.3/20May95-0100AM) id AA23969; Wed, 6 Dec 1995 12:08:08 -0500 Received: by giant.IntraNet.com (DECUS UUCP /2.0/2.0/2.0/); Wed, 6 Dec 95 11:55:23 EST Date: Wed, 6 Dec 95 11:55:23 EST Message-Id: <0099A75A30706D60.40602347@giant.IntraNet.com> From: "G. Del Merritt" Subject: Re: FW: chroot/setuid vs type enforcement To: Firewalls@GreatCircle.COM X-Vms-Mail-To: uucp%"Firewalls@GreatCircle.COM" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In-reply-to: mdr@vodka.sse.att.com's message of 5 Dec 1995 15:29:28 -0500 (EST) >I think we're probably all guilty of writing a bug or two somewhere. Testing only proves the presence of bugs. -- Del Merritt del@IntraNet.com IntraNet, Inc., One Gateway Center #700, Newton, MA 02158 Voice: 617-527-7020; FAX: 617-527-6779 Just say no to Clipper. From firewalls-owner Wed Dec 6 10:29:57 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA07992 for firewalls-outgoing; Wed, 6 Dec 1995 09:43:53 -0800 (PST) Received: from galois.dgaesc.unam.mx (galois.dgaesc.unam.mx [132.248.103.15]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA07984 for ; Wed, 6 Dec 1995 09:43:42 -0800 (PST) Received: (from fw@localhost) by galois.dgaesc.unam.mx (8.6.11/8.6.9) id LAA13617; Wed, 6 Dec 1995 11:50:02 -0600 Received: from laplace.dgaesc.unam.mx(132.248.103.19) by galois via smap (V1.3) id sma013614; Wed Dec 6 11:49:40 1995 Received: from laplace by laplace.dgaesc.unam.mx (5.x/SMI-SVR4) id AA01720; Wed, 6 Dec 1995 11:46:28 -0600 Date: Wed, 6 Dec 1995 11:46:28 -0600 (CST) From: Luis M Ibarra X-Sender: mibarra@laplace To: =?ISO-8859-1?Q?Kristian_K=F6hntopp?= Cc: firewalls@GreatCircle.COM Subject: Re: Small Demo scanner required. In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Wed, 6 Dec 1995, =?ISO-8859-1?Q?Kristian_K=F6hntopp?= wrote: > *get* *permission* to do so. You all remember what happened to > Randal Schwartz, don't you? Sorry for be such an ignorant (this maybe is off the point), but... Who is Randal Schwartz? and, what hapend to him? -- Luis M. Ibarra UNAM, DGAE. From firewalls-owner Wed Dec 6 10:57:11 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA06438 for firewalls-outgoing; Wed, 6 Dec 1995 08:36:48 -0800 (PST) Received: from wotan.compaq.com (wotan.compaq.com [131.168.249.254]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA06430 for ; Wed, 6 Dec 1995 08:36:44 -0800 (PST) From: ESterling@bangate.compaq.com Received: from twisto.eng.hou.compaq.com(really [131.168.254.216]) by wotan.compaq.com via sendmail with smtp id for ; Wed, 6 Dec 95 10:11:26 -0600 (CST) (/\##/\ Smail3.1.30.13 #30.4 built 17-oct-95) Received: from bangate.compaq.com(really [131.168.114.234]) by twisto.eng.hou.compaq.com via sendmail with smtp id for ; Wed, 6 Dec 95 10:11:25 -0600 (CST) (/\##/\ Smail3.1.30.13 #30.3 built 13-oct-95) Received: by bangate.compaq.com; Wed, 6 Dec 95 10:11:24 CST Date: Wed, 6 Dec 95 9:44:03 CST Message-ID: X-Priority: 3 (Normal) To: Subject: Total turnkey firewall Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I am familiar with firewall software products, but I am looking for turnkey vendors that provide full related services - VAN and all effort required to connect third parties to it, monitoring , reporting, PAPI hosts for a global partner network. I want a secured ethernet port ,routing only TCP/IP handed off from this third party network to global Enterprise Network. esterling@bangate@compaq.com From firewalls-owner Wed Dec 6 11:11:01 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA08982 for firewalls-outgoing; Wed, 6 Dec 1995 10:22:34 -0800 (PST) Received: from global.globale.net (global.ca [204.101.90.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA08977 for ; Wed, 6 Dec 1995 10:22:29 -0800 (PST) Received: from globale.net (ppp21.globale.net [204.101.90.21]) by global.globale.net (8.6.8.1/SCA-6.6) with SMTP id SAA12870 for ; Wed, 6 Dec 1995 18:19:54 GMT Date: Wed, 6 Dec 1995 18:19:54 GMT Message-Id: <199512061819.SAA12870@global.globale.net> X-Sender: ecaron@globale.net (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@greatcircle.com From: Eric Caron Subject: Tacacs+ or Radius, that is the question. Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I recently posted a question about remote access authentication and was horrified by the way my mail looked like on the mailing list. My apologies, I'm not used to my mail program and some parameters were not set properly. However, I wish to thank those who answered. I'm sending this new mail to clarify some points. I will repeat that in my opinion, both Tacacs+ and Radius seem to offer similar functionnalities. If I am not wrong, Tacacs+ is more a Cisco thing whereas an implementation of Radius is distributed by Livingston and MIT. If I am still not wrong, both are about to get be IETF certified. Does anyone know which one has a better chance of being a "de facto" standard? Furthermore, if the access server we purchase support both protocols, which one should we prioritize? Our requirements are: 1) The "AAA" functionnalities (Authentication, Authorization, Accounting). 2) PPP protocol. 3) Compatibility with third-party token authentication. 4) Ease of installation, in terms of integration with our actual network. 5) Authentication protocol that is likely to be used and/or supported for a while. If anyone of you can help us in choosing the best protocol, your comments will be much appreciated. Regards, Eric Caron. From firewalls-owner Wed Dec 6 11:24:19 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA10778 for firewalls-outgoing; Wed, 6 Dec 1995 11:09:19 -0800 (PST) Received: from ALABAMA.CF.CS.YALE.EDU (RT-GW.CS.YALE.EDU [128.36.0.13]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id LAA10773 for ; Wed, 6 Dec 1995 11:09:15 -0800 (PST) From: long-morrow@CS.YALE.EDU Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU (8.7.1/res.host.cf-4.0) with ESMTP id OAA03616; Wed, 6 Dec 1995 14:09:53 -0500 (EST) sender long-morrow@CS.YALE.EDU for Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-8.7.1/res.client.cf-4.0) id OAA26449; Wed, 6 Dec 1995 14:09:49 -0500 (EST) Date: Wed, 6 Dec 1995 14:09:49 -0500 (EST) Message-Id: <199512061909.OAA26449@SPARKY.CF.CS.YALE.EDU> To: firewalls@GreatCircle.COM, nlehrer@usia.gov, wbunting@ch.inri.com Subject: Re: tis and udp Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Indeed, the User Datagram Protocol (UDP) could also jokingly be called the following based on its characteristics : Unreliable Datagram Protocol Untraceable Datagram Protocol - Morrow From firewalls-owner Wed Dec 6 11:53:01 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA07456 for firewalls-outgoing; Wed, 6 Dec 1995 09:11:01 -0800 (PST) Received: from nic.abii.com (nic.abii.com [204.77.143.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA07451 for ; Wed, 6 Dec 1995 09:10:55 -0800 (PST) Received: (from mail@localhost) by nic.abii.com (8.6.12/8.6.11) id LAA14156 for ; Wed, 6 Dec 1995 11:11:57 -0600 Received: from mailserv.abii.com(204.77.144.103) by nic.abii.com via smap (V1.3) id sma014146; Wed Dec 6 11:11:44 1995 Received: by mailserv.abii.com with Microsoft Mail id <30C5EA0F@mailserv.abii.com>; Wed, 06 Dec 95 11:07:59 PST From: Garry Garrett To: "'firewalls list from GreatCircle'" Subject: Poking a hole in the firewall Date: Wed, 06 Dec 95 10:15:00 PST Message-ID: <30C5EA0F@mailserv.abii.com> X-Mailer: Microsoft Mail V3.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I have a Web server. This web server needs to get some data off of another machine, inside my firewall. My programmer wants to write his own little home grown TCP/IP application to communicate between his program on my web server and his program on my interal machine. He tests it internally, and it works fine. He puts his application on the web server and I poke a hole in the router and the application does not work. Here's what I've found. I am opening up one TCP port for him to use, but the unix function calls that he's using (the only ones he really knows of) operate like this: Client calls the server on port X. Server responds to Client on port X, giving it a high port number that is available. Client calls the server on that high port number to communicate. This allows for multiple client programs to be fired off. My reaction is, hey, I can poke a hole at some known port number for your application, but I can't just allow some random port number through the router (can I?). His reaction is, hey, I can't just choose the port number that the client is going to use once it's connected. How are these things normally accomplished? I need to have my Web server serve up data that is on an internal machine. What data I need from the internal machine depends upon the search criteria that the Web user entered on their form. Is there some range of port numbers that connect() and accept() are going to use that it's safe for me to allow through my firewall, or better yet, is there a way I can control what port number is assigned to the client so that I can only poke holes for the clients I expect, etc. The web server and the internal machine are both unix boxes. Am I barking up the wrong tree? Is there a better way to be doing this? I've considered a NULL modem cable between the 2 machines, but I'm not sure it can handle the load like TCP/IP can. Garry Garry.Garrett@abii.com From firewalls-owner Wed Dec 6 11:54:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA10980 for firewalls-outgoing; Wed, 6 Dec 1995 11:15:42 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA10975 for ; Wed, 6 Dec 1995 11:15:36 -0800 (PST) Received: from splinter.rtp.dg.com by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA29392; Wed, 6 Dec 1995 14:16:19 -0500 Received: by splinter (8.6.10/rtp-s04) id TAA14073; Wed, 6 Dec 1995 19:15:10 GMT From: spencerj@dg-rtp.dg.com (Jon Spencer) Message-Id: <199512061915.TAA14073@splinter> Subject: Re: How do I remove myself from this list To: andya@aussie.clubfed.sgi.com (Andy Andrews) Date: Wed, 6 Dec 95 14:15:07 EST Cc: firewalls@GreatCircle.com In-Reply-To: <9512060830.ZM2498@aussie.clubfed.sgi.com>; from "Andy Andrews" at Dec 6, 95 8:30 am X-Mailer: ELM [version 2.3 PL11] Sender: firewalls-owner@GreatCircle.COM Precedence: bulk You can check in any time you want, but you can never leave ... > > Hi, > Sorry to post this here, but how do I remove myself from this list ? > Also, is there an equivalent newsgroup I can look at ? > > Thanks > > > > > -- > Come to the edge, He said. > They said, we are afraid. > Come to the edge, He said. > They came. > He pushed them ... and they flew. > --Guillaume Apollinaire > > Andy Andrews > andya@sgi.com > > -- Jon F. Spencer spencerj@rtp.dg.com (uunet!rtp.dg.com!spencerj) Data General Corp. Phone : (919)248-6246 62 T.W. Alexander Dr, MS #119 FAX : (919)248-6108 Research Triangle Park, NC 27709 Office RTP 121/9 Reality is an illusion - perception is what counts. No success can compensate for failure at home. President David O. McKay ***** UCC 1-207 ******** From firewalls-owner Wed Dec 6 12:03:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA07880 for firewalls-outgoing; Wed, 6 Dec 1995 09:38:28 -0800 (PST) Received: from su1.in.net (su1.in.net [199.0.62.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA07875 for ; Wed, 6 Dec 1995 09:38:23 -0800 (PST) Received: from pm2-06.in.net by su1.in.net with SMTP (5.65/1.2-eef) id AA07027; Wed, 6 Dec 95 12:37:49 -0500 Date: Wed, 6 Dec 95 12:37:49 -0500 Message-Id: <9512061737.AA07027@su1.in.net> X-Sender: frankw@in.net X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: nokie@eskimo.com From: frankw@in.net (Frank Willoughby) Subject: Re: Staffing Requirements Cc: firewalls@GreatCircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >One of the divisions of the company I work for has a permanent connection to the >Internet secured by a Tis Toolkit and a Livingston router doing packet >filtering. Since the connection at this division is of limited bandwidth (56k >at present), over the past year or so some 40 to 50 individuals around the >company (nationwide, but primarily at our central location) have obtained >individual accounts with local ISPs in order to get access. These users are >primarily using Spry's Internet in a Box, but there are also some NT users, OS/2 >users, and a couple of Unix machines as well. Since this growth has not been >managed centrally, and we have (also in the last year or so) finished building a >private internet connecting most of our domestic sites, we are concerned about >the risks that these unsecured dial-up connections pose. > >Within the month, the division with the permanent connection will be upgrading >to a T1 which we feel is adequate to meet the needs of the corporation for >Internet access. We plan to move the serial users to connecting via their lan >connections using the bandwidth and the firewall at the division with the >permanent connection. > >My boss (actually my bosses bosses boss, but who's counting) has asked me to >determine the staffing requirements for maintaining and monitoring the firewall. >Our tendency has been to add function without adding headcount; the techs that >are involved in this project feel that this is not an occasion where that is >practical due to the amount of time and effort involved in monitoring logs, etc. >What is the general consensus on the amount of time and effort involved in these >tasks? > >David Nichols -- on my own dime! > > > > David, It depends on the size of your organization, how you implement the firewall, the kind of security level you want, etc. Not knowing any of these things, I would recommend at least two people for this task. One person has the job as a primary function to monitor the firewall & the other is a backup person. Whether both persons work full-time or part-time or has another primary function depends on your environment. Ideally, the firewall doesn't require much maintenance. As always, your mileage may vary (depending on your company's individual requirements). Also: It is imperative that both perons fully understand what can & can't be done. It is best to decide how to handle emergencies in advance. The specific duties & responsibilities should be a formal part of someone's job description. And now for the most important part. Have someone take on the responsibilites of managing the firewall on a full-time basis for a couple of months to see how much of a workload is involved - BEFORE thinking about hiring someone. Four benefits to this: - you can more accurately assess the amount of resources needed - hands-on training for the backup person - decide in advance if there is enough work to keep the person busy - the "do unto others" principle (see next paragraph) IMO, it is wasteful to bring someone on board & then let them go because there is not enough work for them. It is not good for the company, and will put a very large crimp in the employee's life. Even moreso if they have a wife & kids, were hired away from a good job, or had to move to take the position (or any combination thereof). The above wasn't meant to be critical or yours or any organization (and I hope it wasn't received that way). I think you asked a very important question which is often overlooked when putting in a firewall. Best Regards, Frank Fortified Networks Inc. - Management & Information Security Consulting Phone: (317) 573-0800 - http://www.fortified.com/fortified The opinions expressed above are of the author and may not necessarily be representative of Fortified Networks Inc. From firewalls-owner Wed Dec 6 12:24:19 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA10617 for firewalls-outgoing; Wed, 6 Dec 1995 11:05:07 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA10610 for ; Wed, 6 Dec 1995 11:05:02 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id NAA23574; Wed, 6 Dec 1995 13:09:46 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id NAA23570; Wed, 6 Dec 1995 13:09:45 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id NAA16956; Wed, 6 Dec 1995 13:06:36 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id NAA05993; Wed, 6 Dec 1995 13:06:34 -0600 From: Rick Smith Message-Id: <199512061906.NAA05993@shade.sctc.com> Subject: Re: chroot/setuid vs type enforcement To: peter@nmti.com (Peter da Silva) Date: Wed, 6 Dec 1995 13:06:34 -0600 (CST) Cc: smith@sctc.com, anton@the-wire.com, firewalls@GreatCircle.COM In-Reply-To: <9512060019.AA21767@sonic.nmti.com.nmti.com> from "Peter da Silva" at Dec 5, 95 06:19:50 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I wrote: > > To be honest, aren't we really discussing a security model for Unix > > that's been extracted in retrospect? Peter Da Silva replied: > Nope. It was pretty obvious to me at UCB in 1980. I believe that CSRG > understood it too... after all I was just a freshman, they were grad > students. But *today* we're interpreting the model in terms of mandatory access control. At least, that's the distinction between Type Enforcement and chroot(). TE has always been an explicit mechanism to unconditionally block accesses according to explicit permissions. While they may have had some security goals in 1980, we can't possibly claim they were trying to do *mandatory* access control. They may have recognized some notion that access control in Unix should focus on the directory structure, but this did not represent a *mandatory* access control objective. The only truly mandatory access control appears in the kernel mode/user mode distinction at the processor level -- not even "root" can make arbitrary code transition into kernel mode during normal system operation (well, not directly). One reason chroot() is clearly *not* mandatory access control is because the networking code isn't the only place that chroot() style protection is broken. What about access to raw devices? A fellow here who's been looking at chroot() likes to talk about how it only protects access to the "cooked" file system while allowing backdoor access via the "raw" devices, mknod() and such. At least, he's run some experiments that access supposedly protected data that way. Now, I know we can trot out another bandaid to fix mknod(), but don't we have a pattern here? This is beginning to look like the problem of keeping naughty users from achieving root -- there's always one more hole hidden under some subdirectory or an unexpectedly transitive trust relationship. This comes from not having a set of mandatory protection objectives *up* *front* and designing to achieve them. Rick. smith@sctc.com secure computing corporation From firewalls-owner Wed Dec 6 12:39:05 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA06734 for firewalls-outgoing; Wed, 6 Dec 1995 08:52:08 -0800 (PST) Received: from su1.in.net (su1.in.net [199.0.62.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA06729 for ; Wed, 6 Dec 1995 08:52:03 -0800 (PST) Received: from pm2-06.in.net by su1.in.net with SMTP (5.65/1.2-eef) id AA04367; Wed, 6 Dec 95 11:52:18 -0500 Date: Wed, 6 Dec 95 11:52:18 -0500 Message-Id: <9512061652.AA04367@su1.in.net> X-Sender: frankw@in.net X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@GreatCircle.com From: frankw@in.net (Frank Willoughby) Subject: Re: selection criteria? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Mike Shaver wrote: >Thus spake Marcus J. Ranum: >> I played a naughty little game at a conference recently >> where I polled the room by show-of-hands as to what were the >> important things they looked for in firewalls. Features, price, >> and vendor reputation were pretty much the top categories. I'd >> cheated and left "security" off my list and I thought I was going >> to get away with it until someone flagged me when I asked "are >> there any criteria I forgot to put on the list...?" > >I'm beginning to feel a little lonely, but am I _really_ the only one >who sees security as a feature? In my mind, a feature is "something >it does". Whether that's provide a point-and-drool puncture apparatus >for the packet filtering (mjr-esque "feature") or provide a >bulletproof defense against IP spoofing (mjr-esque "security") matters >not. Mike, A firewall is first and foremost a security product and should be evaluated as such. I am surprised that people aren't evaluating them in that light and that the people are concentrating on other areas instead. If you are purchasing a firwall that is vulnerable to one or more security vulnerabilities, then the firewall isn't fulfillling its function and you are wasting your money. A couple of my favorites: GUIs "Hey, cool GUI interface" (forgetting that the GUI itself represents an increased risk of a potential security vulnerability which can be exploited &/or that it may use X-windows which is another security problem in itself). Firewall to firewall encryption An excellent idea - provided that the keys are changed frequently & securely. A hacker can monitor the traffic (dumping it into a file, crack it, & produce the key. After the key has been compromised, the company's confidential data can also be compromised. How many firewall vendors change the key for each session? Only one that I know of. (if there are more, please drop me a line). SecurID. "Neat. Your firewall uses SecurID." Forgetting in the process that Authentication (of users on the 'net) which isn't tightly coupled with Encryption offers *no* protection from Terminal Session Hijacking attempts. The firewall is installed on top of the O/S. Briefly, putting a secure firewall on an *insecured* O/S results in only the illusion of security. Unless the O/S has been secured (MLS, hardened O/S, etc), then the O/S is vulnerable to attacks. If successful, they can compromise the firewall, and then the LAN/WAN which the firewall is trying to protect. The O/S is the weak link in the chain in this case. Terminal Session Hijacking You need encryption from the User on the Internet (outside the firewall) to the firewall itself. At last count, a whopping >3< firewall vendors have this capability. TCP Sequence Number Prediction Attacks "All firewalls can prevent TCP Sequence Number Prediction Attacks." Sure - IF all of your inside addresses are clean & no one on your entire network trusts anyone else. This is the way it should be, but seldom is. I personally know of a company which has several *thousand* rogue IP addresses. Seems that when they did their network planning, no one ever gave any thought of connecting to the Internet. . It will cost them a mint to clean up that mess. They aren't the only one I am familiar with. (They have just taken the problem to extremes). Node Spoofing (by itself) "All firewalls can prevent Node Spoofing."Again, Sure - if all of your inside addresses are clean & you don't trust anyone on the outside, then this problem isn't that large. The above are basic vulnerabilities that have been covered in many books & papers. Shame that they aren't given much thought when the firewalls are enhanced by (most of the) vendors or evaluated by customers. > >Mike >(completely secure that, if he is in fact the only one, he will soon >find out why ;) ) > >-- >#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation <# >#> Technical Specialist -- will tame sendmail(8) for food <# >#> <# >#> "You are a very perverse individual, and I think I'd like to get to <# >#> know you better." --- eric@reference.com <# > > > Best Regards, Frank Fortified Networks Inc. - Management & Information Security Consulting Phone: (317) 573-0800 - http://www.fortified.com/fortified The opinions expressed above are of the author and may not necessarily be representative of Fortified Networks Inc. From firewalls-owner Wed Dec 6 12:51:49 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA05885 for firewalls-outgoing; Wed, 6 Dec 1995 08:19:24 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA05878 for ; Wed, 6 Dec 1995 08:19:19 -0800 (PST) Date: Wed, 6 Dec 1995 11:20:16 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951206112016.20217758@hobbes.orl.mmc.com> Subject: re "security a feature" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Mike rote: >I'm beginning to feel a little lonely, but am I _really_ the only one >who sees security as a feature? Well, I do not look at it that way. My concept of a firewall is not to provide security but to provide controlled functionality. Security says "let nothing in or out without permission". The firewall grants that permission. Is two sides of the same question but then I view my job as not telling people they cannot do things but rather one of assessing their needs and then telling them how to do it safely ("falling with style"). Warmly, Padgett ps Just back from NIST key-escrow conference in Gaithersburg. Corporations who meet IMNSHO logical requirements will be allowed to hold their own keys (a major posture change). 64 bit keylength requirement is dumb but probably enough. Only session/message keys must be escrowed, ignition/key exchange mechanism is open (so what we use assymetric keys (e.g. RSA, D-H, public key/private key) for is not an issue - PGP would be legal if the IDEA component's key was 64 bits or less and escrowed. Lots more happened - still trying to consolodate my thoughts but went in hopeful and came away optomistic. From firewalls-owner Wed Dec 6 12:52:58 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA05235 for firewalls-outgoing; Wed, 6 Dec 1995 08:02:21 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA05229 for ; Wed, 6 Dec 1995 08:02:09 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id KAA17430; Wed, 6 Dec 1995 10:06:33 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id KAA17420; Wed, 6 Dec 1995 10:06:30 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id KAA12267; Wed, 6 Dec 1995 10:03:24 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id KAA00750; Wed, 6 Dec 1995 10:03:24 -0600 From: Rick Smith Message-Id: <199512061603.KAA00750@shade.sctc.com> Subject: Re: Firewall Selection Criteria To: mrm@alpharel.com (Mike Murphy) Date: Wed, 6 Dec 1995 10:03:24 -0600 (CST) Cc: smith@sctc.com, firewalls@GreatCircle.COM In-Reply-To: <199512060041.QAA17600@visalia.optigfx.com> from "Mike Murphy" at Dec 5, 95 04:41:17 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > >Mike Murphy asks: > Yes. I have a simple idea of how to warrant a firewall. > > "If the system(s) protected by this firewall is(are) entered > in an unauthorized manner through the firewall, then Blort > Industries will pay arbitrated damages in an amount not to > exceed $1.25e6 US. Determination of unauthorized entry will > be verified by court appointed arbitrator." > > This is a "put your money where your mouth is" warranty. I'll hold my > breath until some vendor grants something similar. (Us too. :-) Okay. You have just been appointed arbitrator. What do you do to "verify" the claim one way or the other? And be fair. Look at it from both sides, not favoring either the vendor or client. Rick. smith@sctc.com secure computing corporation From firewalls-owner Wed Dec 6 12:54:19 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA14032 for firewalls-outgoing; Wed, 6 Dec 1995 12:35:04 -0800 (PST) Received: from firewall.chancery.com (firewall.chancery.com [206.63.21.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA14008 for ; Wed, 6 Dec 1995 12:34:53 -0800 (PST) Received: from alexmccubbin.chancery.com (alexmccubbin.chancery.com [199.60.53.36]) by firewall.chancery.com (8.6.12/8.6.9) with SMTP id MAA11978; Wed, 6 Dec 1995 12:35:16 -0800 Received: by alexmccubbin.chancery.com with Microsoft Mail id <01BAC3D7.8739B140@alexmccubbin.chancery.com>; Wed, 6 Dec 1995 12:36:56 -0800 Message-ID: <01BAC3D7.8739B140@alexmccubbin.chancery.com> From: Alex McCubbin To: "'firewalls@GreatCircle.COM'" , "'Socks (Internet)'" Subject: SOCKS vs. IPFW Masquerading in Linux Date: Wed, 6 Dec 1995 12:36:50 -0800 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk As far as security concerns, and not knocking Linux for what it is worth, what are the big differences between using SOCKS and IP masquerading? (on a Linux box with firewalling and IP forwarding not compiled into the kernel) >From what I understand conceptually, SOCKS takes packets coming into it and forwards them to the outside world and sends the replies (acks) to the originator. IPFW with masquerading takes packets coming into it and forwards them to the outside world and sends the replies (acks) to the originator... Am I way off base, and missing something drastically in the difference with regards to security on that machine? I'll elaborate with more information if needed, but I think you get the jist of what I'm asking... =) Thanks, Alex... From firewalls-owner Wed Dec 6 13:53:35 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA12806 for firewalls-outgoing; Wed, 6 Dec 1995 12:01:24 -0800 (PST) Received: from mail.yk.rim.or.jp (mail.yk.rim.or.jp [202.247.130.37]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id MAA12797 for ; Wed, 6 Dec 1995 12:01:13 -0800 (PST) Received: from gw2k-4dx2 (ppp031.yk.rim.or.jp [202.247.134.31]) by mail.yk.rim.or.jp (8.7.1/3.4Wbeta6-rim1.1) with SMTP id FAA07999; Thu, 7 Dec 1995 05:02:06 +0900 (JST) Date: Thu, 7 Dec 1995 05:02:06 +0900 (JST) Message-Id: <199512062002.FAA07999@mail.yk.rim.or.jp> Content-Type: text/plain; charset=iso-2022-jp To: firewalls@greatcircle.com Subject: What is "NetsysIXA" ? From: Shuzo Ishihara X-Mailer: Winbiff [version 1.22] References: Mime-Version: 1.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I'd like to know what is "NetsysIXA". I'v heard that this technology is adaptive to make a network-system connect to Internet more securely. That is, when one company has 2-way-network systems(one is only used for main business, and another is for information and communication), using "NetsysIXA" seems to be helpful to connect latter network-system to Internet, and organize all network system as if it were "one network system". I don't know anything about "NetsysIXA", so any information will be appreciated. That is, books and magazines relating to "NetsysIXA" www, FTP site and newsgroup, etc. Shuzo Ishihara E-mail: ishihara@re.enicom.co.jp (Business) shuzo@yk.rim.or.jp (Personal) Nippon Steel Information & Communication Systems Inc. Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Nippon Steel Information & Communication Systems Inc. From firewalls-owner Wed Dec 6 14:12:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA12772 for firewalls-outgoing; Wed, 6 Dec 1995 12:00:37 -0800 (PST) Received: from [198.102.244.42] (pb520.greatcircle.com [198.102.244.42]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA12764; Wed, 6 Dec 1995 12:00:31 -0800 (PST) X-Sender: brent@miles.greatcircle.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Dec 1995 12:04:18 +0100 To: Garry Garrett , "'firewalls list from GreatCircle'" From: Brent@GreatCircle.COM (Brent Chapman) Subject: Re: Poking a hole in the firewall Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 10:15 AM 12/6/95, Garry Garrett wrote: >I have a Web server. This web server needs to get some data off >of another machine, inside my firewall. My programmer wants to write >his own little home grown TCP/IP application to communicate between >his program on my web server and his program on my interal machine. >He tests it internally, and it works fine. He puts his application on the >web server and I poke a hole in the router and the application does >not work. > >Here's what I've found. I am opening up one TCP port for him to use, >but the unix function calls that he's using (the only ones he really knows >of) operate like this: Client calls the server on port X. Server responds >to Client on port X, giving it a high port number that is available. Client >calls the server on that high port number to communicate. This allows >for multiple client programs to be fired off. If that's really the reason for the server using multiple ports, then your programmer doesn't understand much about how TCP works. You can have multiple client sessions talking to the same server port number, no problem. Services like SMTP, Telnet, FTP, HTTP, and so forth (in fact, just about every Internet service out there) do it all the time. You can do this with multiple connections to a single server process, or to multiple server processes; it doesn't matter. -Brent ----------------------+----------------------------+------------------------ Brent Chapman | Great Circle Associates | 1057 West Dana Street Brent@GreatCircle.COM | http://www.greatcircle.com | Mountain View, CA 94041 ----------------------+----------------------------+------------------------ Internet Tutorials from the Experts! From firewalls-owner Wed Dec 6 15:26:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA16202 for firewalls-outgoing; Wed, 6 Dec 1995 13:33:52 -0800 (PST) Received: from gw1.fbc.com (gw1.fbc.com [198.240.130.66]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA16197 for ; Wed, 6 Dec 1995 13:33:43 -0800 (PST) Received: by gw1.fbc.com (4.1/GW1-v1.1) id AA05300; Wed, 6 Dec 95 16:37:36 EST Received: from unknown(137.34.1.36) by gw1.fbc.com via smap (V1.3) id tma005278; Wed Dec 6 16:37:09 1995 Received: from postoffice.fir.fbc.com (postoffice.fir.fbc.com [137.34.19.134]) by csfb1.fir.fbc.com (8.6.12/8.6.12) with ESMTP id QAA15474; Wed, 6 Dec 1995 16:34:05 -0500 Received: from sysadm-9.fir.fbc.com (sysadm-9.fir.fbc.com [137.34.136.55]) by postoffice.fir.fbc.com (8.6.9/8.6.12) with SMTP id QAA14095; Wed, 6 Dec 1995 16:34:04 -0500 From: Luther Garcia Received: by sysadm-9.fir.fbc.com (4.1) id AA01437; Wed, 6 Dec 95 16:34:03 EST Message-Id: <9512062134.AA01437@sysadm-9.fir.fbc.com> Subject: Re: Poking a hole in the firewall To: GARRYG@omaha.abii.com (Garry Garrett) Date: Wed, 6 Dec 1995 16:34:03 -0500 (EST) Cc: firewalls@greatcircle.com In-Reply-To: <30C5EA0F@mailserv.abii.com> from "Garry Garrett" at Dec 6, 95 10:15:00 am X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > > > I have a Web server. This web server needs to get some data off > of another machine, inside my firewall. My programmer wants to write > his own little home grown TCP/IP application to communicate between > his program on my web server and his program on my interal machine. > He tests it internally, and it works fine. He puts his application on the > web server and I poke a hole in the router and the application does > not work. > Hmm. It depends on how your firewall is built. If say it is composed of a packet filter and some sort of bastion host running proxy servers for telnet and ftp, then you might just want to hook it up in front of your firewall, modify the source to /bin/login and ftp to have hooks to call some sort of authentication code like skey or whatever your preference. If you have sensitive data on it, then you might want to consider throwing a packet filter in front of it, allowing port 80 to the world and filtering all other stuff. It's very nature makes it difficult to make totally secure, but you can try... L; From firewalls-owner Wed Dec 6 15:54:19 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA16183 for firewalls-outgoing; Wed, 6 Dec 1995 13:33:19 -0800 (PST) Received: from su1.in.net (su1.in.net [199.0.62.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA16178 for ; Wed, 6 Dec 1995 13:33:14 -0800 (PST) Received: from pm1-10.in.net by su1.in.net with SMTP (5.65/1.2-eef) id AA21954; Wed, 6 Dec 95 16:33:35 -0500 Date: Wed, 6 Dec 95 16:33:35 -0500 Message-Id: <9512062133.AA21954@su1.in.net> X-Sender: frankw@in.net X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@GreatCircle.com From: frankw@in.net (Frank Willoughby) Subject: Re: Total turnkey firewall Sender: firewalls-owner@GreatCircle.COM Precedence: bulk ESterling writes: >I am familiar with firewall software products, but I am looking for turnkey >vendors that provide full related services - VAN and all effort required to >connect third parties to it, monitoring , reporting, PAPI hosts for a >global partner network. I want a secured ethernet port ,routing only >TCP/IP handed off from this third party network to global Enterprise >Network. > > esterling@bangate@compaq.com > > > It isn't clear from your message whether you are looking for the turnkey vendor to provide the security for you. Regardless, I would like to recommend that a company should *never* outsource *any* part of its Information Security. It is very tempting to do this (particularly from an ISP point of view), but from a security point-of-view, I wouldn't recommend it. Essentially, it is putting control of your company in the hands of someone else (who also might be managing your competitors systems and networks. The potential consequences of doing this could be very damaging - including: - short- & long-term disruption of essential business services - compromise of proprietary or business-critical data - compromise of unpatented technologies - loss of copyrights - disruption of logistics (JIT is another security issue in itself) - compromise of client's confidential data - loss of customers - loss of reputation - Chapter 11 & 13 (bankruptcy proceedings for those not in the USA) - etc. Information Security in many companies is an almost invisible entity that is almost forgotten until budget time rolls around. Like insurance, Information Security is an overhead cost that is essential to business operations. Like insurance, if you don't have it, and you have an immediate need for it, it is often too late. I know that many claim that almost everything can be covered by contracts. Unfortunately, lawsuits often take a long time to settle. A company may have go belly-up long before the suit is settled. Even if the company wins the suit, it is too late to restart business operations & win back the customers who have just gotten burned. I have very recent personal knowledge of a company which has almost commited themselves to outsourcing their Information Security. Hopefully, it isn't too late for them. (FWIW, I am in the middle of preparing a report for them on this subject.) Unfortunately, that company isn't the only one. In the efforts to become efficient and streamline business operations, sometimes upper managlement forgets and starts throwing the baby out with the bathwater. Anyway, if anyone on this list finds the above scenario about to happen to their company, give me a discreet call & I'll see what I can do to help. Hope the above helps. Best Regards, Frank Fortified Networks Inc. - Management & Information Security Consulting Phone: (317) 573-0800 - http://www.fortified.com/fortified The opinions expressed above are of the author and may not necessarily be representative of Fortified Networks Inc. From firewalls-owner Wed Dec 6 16:10:19 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA17765 for firewalls-outgoing; Wed, 6 Dec 1995 14:05:08 -0800 (PST) Received: from mail1.is.net (mail1.is.net [198.69.24.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA17746 for ; Wed, 6 Dec 1995 14:05:01 -0800 (PST) Received: from mrdata.is.net (mrdata.is.net [198.69.24.6]) by mail1.is.net (8.6.11/8.6.12) with SMTP id RAA06345 for ; Wed, 6 Dec 1995 17:01:46 -0500 Date: Wed, 6 Dec 1995 17:58:24 -0500 (EST) From: Alex Filacchione To: firewalls@GreatCircle.COM Subject: Re: selection criteria? In-Reply-To: <199512061308.IAA23228@neon.ingenia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Wed, 6 Dec 1995, Mike Shaver wrote: > Is integrated S/Key a feature? Or is it "security"? Feature > > What are the defining characteristics of a feature, and how do they > contrast the defining characteristics of "security"? > Security is an "End," or end result. Features are simply (a) means to this end, IMO. brain21@ninja.techwood.org alexf@is.net From firewalls-owner Wed Dec 6 16:10:30 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA16731 for firewalls-outgoing; Wed, 6 Dec 1995 13:44:38 -0800 (PST) Received: from su1.in.net (su1.in.net [199.0.62.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA16721 for ; Wed, 6 Dec 1995 13:44:31 -0800 (PST) Received: from pm1-10.in.net by su1.in.net with SMTP (5.65/1.2-eef) id AA22504; Wed, 6 Dec 95 16:44:53 -0500 Date: Wed, 6 Dec 95 16:44:53 -0500 Message-Id: <9512062144.AA22504@su1.in.net> X-Sender: frankw@in.net X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@GreatCircle.com From: frankw@in.net (Frank Willoughby) Subject: Re: Firewall Selection Criteria Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Rick poses a good question in his mail: 8< [snip] > What do you do to >"verify" the claim one way or the other? And be fair. Look at it from >both sides, not favoring either the vendor or client. The easiest way is to test it against most of the known vulnerabilities. The vulnerabilities mentioned in the Firewalls & Internet Security book are a few. Others are mentioned in Steven Bellovin's paper "Security Problems in the TCP/IP Protocol Suite". Worked for me. These two helped me eliminate almost all of the major players in the market. If you are in a hurry, use Steven Bellovin's paper as a measuring stick. (Remember to verify all claims that the vendors make). > >Rick. >smith@sctc.com secure computing corporation > > Best Regards, Frank Fortified Networks Inc. - Management & Information Security Consulting Phone: (317) 573-0800 - http://www.fortified.com/fortified The opinions expressed above are of the author and may not necessarily be representative of Fortified Networks Inc. From firewalls-owner Wed Dec 6 16:43:46 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA17766 for firewalls-outgoing; Wed, 6 Dec 1995 14:05:10 -0800 (PST) Received: from mail1.is.net (mail1.is.net [198.69.24.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA17755 for ; Wed, 6 Dec 1995 14:05:04 -0800 (PST) Received: from mrdata.is.net (mrdata.is.net [198.69.24.6]) by mail1.is.net (8.6.11/8.6.12) with SMTP id QAA06233 for ; Wed, 6 Dec 1995 16:57:31 -0500 Date: Wed, 6 Dec 1995 17:54:08 -0500 (EST) From: Alex Filacchione To: firewalls@GreatCircle.COM Subject: Re: selection criteria? In-Reply-To: <199512061100.GAA22937@neon.ingenia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Wed, 6 Dec 1995, Mike Shaver wrote: > I'm beginning to feel a little lonely, but am I _really_ the only one > who sees security as a feature? In my mind, a feature is "something > it does". Whether that's provide a point-and-drool puncture apparatus > for the packet filtering (mjr-esque "feature") or provide a > bulletproof defense against IP spoofing (mjr-esque "security") matters > not. I don't know how everybody else feel, but I don't think that "security" is a "feature" of a firewall. Security is the GOAL of the firewall, and the "features" help in attaining that goal. It is assumed, by the very nature of firewalls, that security should be the attainable end-result, so to speak. If someone asked me what the most important features of a firewall were I would list things like, price, effectiveness, ease of use, ability to easily customize rules, etc. I would NOT list safety or security, because that is the END result (we hope) of the configuration and use of the available features. I think that most people take this fact or mindset for granted, and concentrate on ways of getting there when talking about features. *that* is probably why seminar surveys end up the way they do. Just my $.02 brain21@ninja.techwood.org alexf@is.net From firewalls-owner Wed Dec 6 16:58:18 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA23885 for firewalls-outgoing; Wed, 6 Dec 1995 16:42:03 -0800 (PST) Received: from interlock.mckesson.com (interlock.mckesson.com [199.221.43.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id QAA23875 for ; Wed, 6 Dec 1995 16:41:55 -0800 (PST) Received: from [128.1.53.159] by interlock.mckesson.com with SMTP id AA08648 (InterLock SMTP Gateway 3.0 for ); Wed, 6 Dec 1995 16:42:51 -0800 Date: Wed, 6 Dec 1995 16:42:51 -0800 Message-Id: <199512070042.AA08648@interlock.mckesson.com> Subject: Re: Firewall Selection Criteria From: Bill Husler Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >Actually, the drug companies do provide guarantees. If the drug >has bad side effects or is ineffective, the drug company may be >held liable. One drug, Thalidomide (sp?), comes immediately to >mind. Big damages. I suppose I could mention what breast implants >did for the manufacturer of the implants, too. > Hmm, isn't this guarantee independent of anything the drug company would like to provide? In that way, a firewall company could indeed find itself in court simply because by marketing a "Secure Firewall" product they are implying the resistance to break-in. I suppose that unless they specify that limit of indemnity, you could go for broke (play on words), as indicated by the above law suits. Bill From firewalls-owner Wed Dec 6 17:20:39 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA17301 for firewalls-outgoing; Wed, 6 Dec 1995 13:54:55 -0800 (PST) Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.6]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA17271 for ; Wed, 6 Dec 1995 13:54:45 -0800 (PST) Received: from smtpgty.saicuk.co.uk by flow.pipex.net with SMTP (PP); Wed, 6 Dec 1995 21:53:14 +0000 Received: by smtpgty.saicuk.co.uk with Microsoft Mail id <30C60F67@smtpgty.saicuk.co.uk>; Wed, 06 Dec 95 21:47:19 GMT From: "Johnson-Bryden, Ian" To: "'firewalls@greatcircle.com'" Subject: Re: selection criteria? Date: Wed, 06 Dec 95 19:10:00 GMT Message-ID: <30C60F67@smtpgty.saicuk.co.uk> X-Mailer: Microsoft Mail V3.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >Karim wrote: >Is availability of resources a feature to your users? Is privacy (or at least >some art of confidentiality) a feature to your users? >If you answer to those 2 questions by yes, then you might want to scrap >every kind of "security" your organisation has, beginning with door locks. >If you answer no to at least one of the two questions above then you might >want to consider security more then just a feature. 'privacy' and 'security' are subjects and arguably subjective description. 'privacy' as a subject covers a range of techniques and technologies, as does 'security'. Each technique and all technology comprises features which offer benefits. You could decide to employ 'privacy' as an essential part of your risk policy but you would then have to procure products/systems to provide a required level of 'privacy'. Procuring those products would demand that you could specify your requirements to vendors and be able to measure their responses to you. You also need to measure one submission against another. That was a major motivation of drafting Orange Book and all the criteria which have followed since. Someone else takes responsibility for measuring a product and certifying compliance to save every customer having to evaluate a product in detail. Therefore you can say a B1 achievement is a feature of the product. The benefit might be that this includes MAC which is necessary to meet your security targets for the system. Ian J-B From firewalls-owner Wed Dec 6 17:38:07 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA23699 for firewalls-outgoing; Wed, 6 Dec 1995 16:37:22 -0800 (PST) Received: from hermes.intel.com (hermes.intel.com [143.183.152.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id QAA23694 for ; Wed, 6 Dec 1995 16:37:19 -0800 (PST) Received: from argus.intel.com by hermes.intel.com (8.7.1/10.0i); Wed, 6 Dec 1995 16:38:15 -0800 Received: by argus.intel.com (8.7.1/10.0i); Wed, 6 Dec 1995 16:38:12 -0800 From: sedayao@argus.intel.com (Jeffrey C. Sedayao) Message-Id: <199512070038.QAA06034@argus.intel.com> Subject: Randal Schwartz (was Re: Small Demo scanner required.) To: @argus.intel.com:mibarra@galois.dgaesc.unam.mx (Luis M Ibarra) Date: Wed, 6 Dec 95 16:38:11 PST Cc: firewalls@greatcircle.com In-Reply-To: from "Luis M Ibarra" at Dec 6, 95 11:46:28 am X-Mailer: ELM [version 2.4dev PL66] MIME-Version: 1.0 Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > On Wed, 6 Dec 1995, =?ISO-8859-1?Q?Kristian_K=F6hntopp?= wrote: > > *get* *permission* to do so. You all remember what happened to > > Randal Schwartz, don't you? > Sorry for be such an ignorant (this maybe is off the point), but... > Who is Randal Schwartz? and, what hapend to him? He is a guy with poor judgment who puts holes in your firewalls when you aren't looking (or are too trusting). > -- > Luis M. Ibarra > UNAM, DGAE. -- Jeff Sedayao Intel Corporation sedayao@argus.intel.com From firewalls-owner Wed Dec 6 17:48:40 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA18554 for firewalls-outgoing; Wed, 6 Dec 1995 14:24:07 -0800 (PST) Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA18538 for ; Wed, 6 Dec 1995 14:24:00 -0800 (PST) Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by stilton.cisco.com (8.6.8+c/8.6.5) with ESMTP id OAA11016; Wed, 6 Dec 1995 14:23:58 -0800 Message-Id: <199512062223.OAA11016@stilton.cisco.com> To: Eric Caron Cc: firewalls@GreatCircle.COM Subject: Re: Tacacs+ or Radius, that is the question. In-Reply-To: Your message of "Wed, 06 Dec 1995 18:19:54 GMT." <199512061819.SAA12870@global.globale.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <11012.818288637.1@cisco.com> Date: Wed, 06 Dec 1995 14:23:58 -0800 From: David Carrel Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Eric, I can comment on this, but I am undoubtedly biased as I work for cisco, and in fact designed and wrote TACACS+. RADIUS is probably more of a defacto standard, but both are publicly documented protocols. RADIUS is going through the IETF, but I certainly wouldn't call this a certification. This is not a process open to all protocols and intending to find the best protocol, but is merely a process of documenting "what is standard RADIUS". The distinction is significant. As far as the two go, I believe that TACACS+ is the better protocol. cisco provides both to our customers, but RADIUS cannot provide the functionality that TACACS+ does. Hence we recommend TACACS+ unless the customer needs RADIUS because of a multivendor environment. TACACS+ provides authentication, authorization and accunting as separate services, not combined services. TACACS+ authorization is dynamic and can be tied into other dynamic negotiations such as PPP negotiations. RADIUS is a one-shot deal. You authenticate and you get a fixed list of all the things you can do. With TACACS+, you authenticate first, then run separate authorizations for each service and if necessary, can run multiple authoriastions for a service. The TACACS+ spec is available in ftp://ftp.cisco.com/pub/tacacs/ Get the file README to get the exact file name. Dave ---------------------------------------------------------------------------- David Carrel | E-mail: carrel@cisco.com Security Development, cisco Systems | phone: (408) 526-5207 170 W. Tasman Drive | fax: (408) 526-4952 San Jose, CA 95134-1706 | ---------------------------------------------------------------------------- > I recently posted a question about remote access authentication and was > horrified by the way my mail looked like on the mailing list. My apologies, > I'm not used to my mail program and some parameters were not set properly. > However, I wish to thank those who answered. I'm sending this new mail to > clarify some points. > > I will repeat that in my opinion, both Tacacs+ and Radius seem to offer > similar functionnalities. If I am not wrong, Tacacs+ is more a Cisco thing > whereas an implementation of Radius is distributed by Livingston and MIT. > If I am still not wrong, both are about to get be IETF certified. Does > anyone know which one has a better chance of being a "de facto" standard? > Furthermore, if the access server we purchase support both protocols, which > one should we prioritize? > > Our requirements are: > > 1) The "AAA" functionnalities (Authentication, Authorization, Accounting) > . > 2) PPP protocol. > 3) Compatibility with third-party token authentication. > 4) Ease of installation, in terms of integration with our actual network. > 5) Authentication protocol that is likely to be used and/or supported > for a while. > > If anyone of you can help us in choosing the best protocol, your comments > will be much appreciated. > > > Regards, > > Eric Caron. > > From firewalls-owner Wed Dec 6 17:54:20 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA24350 for firewalls-outgoing; Wed, 6 Dec 1995 16:59:32 -0800 (PST) Received: from safety.worldcom.com (safety.worldcom.com [198.64.193.5]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id QAA24344 for ; Wed, 6 Dec 1995 16:59:27 -0800 (PST) Received: (from smtp@localhost) by safety.worldcom.com (8.7.1/8.6.9) id SAA25297 for ; Wed, 6 Dec 1995 18:19:17 -0600 (CST) Received: from worldcom-45.worldcom.com(198.64.193.76) by safety.worldcom.com via smap (V1.3) id sma025211; Wed Dec 6 18:18:17 1995 Received: by worldcom-45.worldcom.com (IBM OS/2 SENDMAIL VERSION 1.3.14/3.3) id AA2144; Wed, 06 Dec 95 18:18:32 -0500 Message-Id: <9512062318.AA2144@worldcom-45.worldcom.com> Received: from worldcom with "Lotus Notes Mail Gateway for SMTP" id D73B5AA2322ADA708625628B00015B69; Wed, 6 Dec 95 18:18:32 To: firewalls From: Kenneth Smith Date: 6 Dec 95 15:58:50 Subject: Re: chroot/setuid vs type enforcement Mime-Version: 1.0 Content-Type: Text/Plain Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Rick Smith wrote: >Now, I know we can trot out another bandaid to fix mknod(), but don't >we have a pattern here? This is beginning to look like the problem of >keeping naughty users from achieving root -- there's always one more >hole hidden under some subdirectory or an unexpectedly transitive >trust relationship. This comes from not having a set of mandatory >protection objectives *up* *front* and designing to achieve them. Without getting too far off track . . . isn't this what MS has attempted to do with NT? I'm well aware that NT is still relatively new and unproven, but if we are to believe Microsoft's press releases, at any rate, these are precisely some of the design goals they had in mind. There are undoubtedly a number of problems to be worked out, but it does seem to me that among the mainstream OS's, NT has the best claim to having been designed with a clear set of security objectives. I would be willing to admit that, at the moment, Unix can be made more secure than NT (it's had 20 years or so to get the bugs worked out) -- but it seems to me that NT has better potential. Ken Smith Independent National Mortgage From firewalls-owner Wed Dec 6 17:58:38 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA17351 for firewalls-outgoing; Wed, 6 Dec 1995 13:56:56 -0800 (PST) Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.6]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA17346 for ; Wed, 6 Dec 1995 13:56:48 -0800 (PST) Received: from smtpgty.saicuk.co.uk by flow.pipex.net with SMTP (PP); Wed, 6 Dec 1995 16:59:23 +0000 Received: by smtpgty.saicuk.co.uk with Microsoft Mail id <30C5CA3E@smtpgty.saicuk.co.uk>; Wed, 06 Dec 95 16:52:14 GMT From: "Johnson-Bryden, Ian" To: "'firewalls@greatcircle.com'" Subject: RE: Staffing Requirements Date: Wed, 06 Dec 95 16:56:00 GMT Message-ID: <30C5CA3E@smtpgty.saicuk.co.uk> X-Mailer: Microsoft Mail V3.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >David Nichols wrote: >My boss (actually my bosses bosses boss, but who's counting) has asked me to >determine the staffing requirements for maintaining and monitoring the >firewall. that >are involved in this project feel that this is not an occasion where that is >practical due to the amount of time and effort involved in monitoring logs, >etc. >What is the general consensus on the amount of time and effort involved in >these >tasks? Having carried out an audit earlier this year for 2 organisations in a similar line of business and of a similar size, I found some significant differences in all aspects of their respective operations - no surprise in that. One difficulty of posting to firewalls is that you may have some highly capable people reading your post and keen to comment, but you cant really publically post the level of information to make it much more than a 'how long is a piece of string?' question. There are some basic considerations though. If you take security seriously, you should work on the basis of three job groups; systems administrator; network administrator; security officer. The reasons being that this avoids overloading with the risk of neglect of a critical task, and it provides for guarding guards. However, there are many sites where one person is expected to do everything which may or may not be reasonable for work loading, but does not provide much supervisory assurance. If you have a large site with a number of divisional systems inside the site, or a number of geographically separated sites, it may be possible/desirable/necessary to remote all management functions to one point, or each site may function on its own. This could mean you need to have a 3 man team on each site, a 3 man team centrally, a central team and a smaller team per site. That being a security consideration which is then modified by the system activity/work load for each site. One challenge you might face is creeping functionality which is what it sounds like from your posting. It is not unusual for an organisation to take the 'the solution is a firewall so lets not worry about the problem'. That approach often results in a roll-your-own firewall of some description. The first implementation does not filter very much and the traffic levels may be low. Traffic builds, supervisors see FUD postings, senior management read horror stories in the newspapers, etc., and the firewall gets ever tighter, constricting traffic, frustrating users, encouraging end users to open back doors through SLIP connections etc. The MIS department which put the system in rapidly gets to the point where it doesnt have the manpower to manage the firewall. Logs just dont get read, the firewall is heavily compromised, and security becomes virtually non-existent. Right now maybe only you know what your situation is. It could be that you need several new people to manage the firewall and read the logs adequately, but it might be that you are screening traffic at a much tighter level than you need. You only really know that if you have a real security policy which is maintained and enforced, but then if you worked that way you should not have the problem you appear to have. You could need one further job group. This might be only one person but could require several depending on the size of your organisation. This job group is the enforcement function. The remit is to audit what actually happens in the organisation and audits the performance against the security policy. Some organisations would consider this group to have a wide remit which includes a range of activities and situations including ensuring that only legal licensed software is used and that equipment is located where the asset register says it should be. The next issue is where these jobs should be located and whether they can be adequately covered by existing personnel or require further recruitment. The enforcement group might for example be the folk who sit in reception and walk the building at night. If so, they may be able to do the job but require retraining. The same could apply to MIS personnel who have spare capacity which could be redirected in part with suitable training. Ian J-B From firewalls-owner Wed Dec 6 18:15:46 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA23436 for firewalls-outgoing; Wed, 6 Dec 1995 16:25:23 -0800 (PST) Received: from enny01.enicom.co.jp (enny01.enicom.co.jp [202.33.90.66]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id QAA23431 for ; Wed, 6 Dec 1995 16:25:16 -0800 (PST) Received: by enny01.enicom.co.jp (8.7.1+2.6Wbeta4/3.3W9/enicom1995.05.19) with UUCP id JAA04470 for firewalls@greatcircle.com; Thu, 7 Dec 1995 09:23:57 +0900 (JST) Received: from re.enicom.co.jp by enicom.rd.enicom.co.jp (8.6.12+2.5Wb7/3.3W9/enicom5.0) with ESMTP id JAA11098 for ; Thu, 7 Dec 1995 09:20:35 +0900 Received: from (MTD2001 [133.179.8.32]) by re.enicom.co.jp (8.6.11+2.4W/3.4W/re1.4) with SMTP id JAA19919 for firewalls@greatcircle.com; Thu, 7 Dec 1995 09:18:39 +0900 Date: Thu, 7 Dec 1995 09:18:39 +0900 Message-Id: <199512070018.JAA19919@re.enicom.co.jp> From: Shuzo Ishihara To: firewalls@greatcircle.com Mime-Version: 1.0 Subject: Re: What is "NetsysIXA" ? Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Winbiff [version 1.07] Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Sorry for sendig following message. I made mistakes sending it to this mailing-list. Please disregard following message. >I'd like to know what is "NetsysIXA". > >I'v heard that this technology is adaptive to make a network-system >connect to Internet more securely. > >That is, when one company has 2-way-network systems(one is only used >for main business, and another is for information and communication), >using "NetsysIXA" seems to be helpful to connect latter network-system >to Internet, and organize all network system as if it were >"one network system". > >I don't know anything about "NetsysIXA", so any information will be >appreciated. That is, > books and magazines relating to "NetsysIXA" > www, FTP site and newsgroup, etc. Shuzo Ishihara E-mail: ishihara@re.enicom.co.jp(Business) shuzo@yk.rim.or.jp(Personal) Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Nippon Steel Information & Communication Systems Inc. From firewalls-owner Wed Dec 6 18:24:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id RAA26433 for firewalls-outgoing; Wed, 6 Dec 1995 17:55:45 -0800 (PST) Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id RAA26426 for ; Wed, 6 Dec 1995 17:55:40 -0800 (PST) Received: from netsystech.com by relay4.UU.NET with SMTP id QQztad22755; Wed, 6 Dec 1995 20:56:29 -0500 (EST) Received: from netsys30.netsystech.com by netsystech.com (5.0/SMI-SVR4) id AA21931; Wed, 6 Dec 1995 18:00:12 -0800 Date: Wed, 6 Dec 1995 18:00:12 -0800 From: awilson@netsys1.netsystech.com (Anne Wilson - Ext 508) Message-Id: <9512070200.AA21931@netsystech.com> To: firewalls@greatcircle.com, shuzo@yk.rim.or.jp Subject: Re: What is "NetsysIXA" ? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Well, we are Netsys Technologies Inc, but we do network validation and planning tools for Cisco router networks - you can use the simulation software to validate the access lists on your router, but we don't call it "NetsysIXA" .... regards Anne CM Wilson http://www.netsystech.com From firewalls-owner Wed Dec 6 18:38:47 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA20679 for firewalls-outgoing; Wed, 6 Dec 1995 15:22:50 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.235.77]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id PAA20674 for ; Wed, 6 Dec 1995 15:22:46 -0800 (PST) Received: from pferguso-pc.cisco.com (c1robo15.cisco.com [171.68.13.25]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id PAA02551 for ; Wed, 6 Dec 1995 15:23:27 -0800 Message-Id: <199512062323.PAA02551@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Dec 1995 18:23:44 -0500 To: firewalls@GreatCircle.COM From: Paul Ferguson Subject: Re: Tacacs+ or Radius, that is the question. Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Yes; T+ is a cisco thing. No; it (TACACS+) has not been presented to the IETF for standardization. I would suggest that you join the RADIUS IETF Working Group list (surprise!) at ietf-radius-request@livingston.com. We had a WG meeting yesterday, in fact, where some of this was discussed. The meeting got somewhat sidetracked, in my opinion, on administrative issues, but the group exists nonetheless. Carl Rigney, of Livingston, is the WG chair; Pat Calhoun, of US Robotics, is the RFC/Draft editor. If you want to peruse the current drafts, ftp to ds.internic.net:/internet-drafts, and look for draft-ietf-radius*. - paul At 06:19 PM 12/6/95 GMT, Eric Caron wrote: >I recently posted a question about remote access authentication and was >horrified by the way my mail looked like on the mailing list. My apologies, >I'm not used to my mail program and some parameters were not set properly. >However, I wish to thank those who answered. I'm sending this new mail to >clarify some points. > >I will repeat that in my opinion, both Tacacs+ and Radius seem to offer >similar functionnalities. If I am not wrong, Tacacs+ is more a Cisco thing >whereas an implementation of Radius is distributed by Livingston and MIT. >If I am still not wrong, both are about to get be IETF certified. Does >anyone know which one has a better chance of being a "de facto" standard? >Furthermore, if the access server we purchase support both protocols, which >one should we prioritize? > >Our requirements are: > > 1) The "AAA" functionnalities (Authentication, Authorization, Accounting). > 2) PPP protocol. > 3) Compatibility with third-party token authentication. > 4) Ease of installation, in terms of integration with our actual network. > 5) Authentication protocol that is likely to be used and/or supported >for a while. > >If anyone of you can help us in choosing the best protocol, your comments >will be much appreciated. > > >Regards, > >Eric Caron. > > > > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso@cisco.com c i s c o S y s t e m s From firewalls-owner Wed Dec 6 18:53:33 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA23560 for firewalls-outgoing; Wed, 6 Dec 1995 16:32:02 -0800 (PST) Received: from safety.worldcom.com (safety.worldcom.com [198.64.193.5]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id QAA23555 for ; Wed, 6 Dec 1995 16:31:58 -0800 (PST) Received: (from smtp@localhost) by safety.worldcom.com (8.7.1/8.6.9) id SAA23680 for ; Wed, 6 Dec 1995 18:02:57 -0600 (CST) Received: from worldcom-45.worldcom.com(198.64.193.76) by safety.worldcom.com via smap (V1.3) id sma023603; Wed Dec 6 18:02:14 1995 Received: by worldcom-45.worldcom.com (IBM OS/2 SENDMAIL VERSION 1.3.14/3.3) id AA1684; Wed, 06 Dec 95 17:59:46 -0500 Message-Id: <9512062259.AA1684@worldcom-45.worldcom.com> Received: from worldcom with "Lotus Notes Mail Gateway for SMTP" id C36338BF5AEDF78A8625628A0083688C; Wed, 6 Dec 95 17:59:45 To: firewalls From: Kenneth Smith Date: 6 Dec 95 15:50:06 Subject: NT Security and NTFS Mime-Version: 1.0 Content-Type: Text/Plain Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Questions about NT security have been tossed around quite a bit lately, but I have a new one to add to the pot. One of the claims which NT makes to security is its NTFS file system, which unlike FAT supports permissions natively. It is, for instance, a required element of NT's C2 configuration. But as I understand it . . . wouldn't it be possible to write or obtain an NTFS file system driver for some alternate OS which supports installable file systems (i.e., Windows 95, Linux)? If this is the case, wouldn't this mean that booting to or installing that OS on anotherwise supposedly secure system would grant the user unrestricted access to the file system? I would imagine that some enterprising individual could even come up with a way to boot the file system and a simple command-line interface off of a floppy. I know that this question presupposes physical access to the machine in question, and if that happens there are any number of possible back-doors, but it still strikes me as a rather large loophole. Comments? Ken Smith Independent National Mortgage From firewalls-owner Wed Dec 6 18:54:19 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id RAA25452 for firewalls-outgoing; Wed, 6 Dec 1995 17:33:06 -0800 (PST) Received: from necsin-fw.nec.com.sg ([203.127.255.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id RAA25434 for ; Wed, 6 Dec 1995 17:32:57 -0800 (PST) Received: from kato.nec.com.sg ([203.127.254.2]) by necsin-fw.nec.com.sg (8.6.12+2.5Wb7/3.4W/10/05/95) with ESMTP id BAA04340 for ; Thu, 7 Dec 1995 01:33:19 GMT Received: from necsin.nec.com.sg ([203.127.253.222]) by kato.nec.com.sg (8.6.12+2.5Wb7/3.4W/10/06/95) with SMTP id BAA23531 for ; Thu, 7 Dec 1995 01:32:58 GMT Received: from NEC-Message_Server by necsin.nec.com.sg with Novell_GroupWise; Thu, 07 Dec 1995 09:34:57 +0800 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 07 Dec 1995 09:34:31 +0800 From: Xin LI To: andya@aussie.clubfed.sgi.com, firewalls@GreatCircle.com Subject: How do I remove myself from this list -Reply Sender: firewalls-owner@GreatCircle.COM Precedence: bulk You can try as following instruction: If you ever want to remove yourself from this mailing list, you can send mail to "Majordomo@GreatCircle.COM" with the following command in the body of your email message: unsubscribe firewalls andya@aussie.clubfed.sgi.com or andya@sgi.com >>> Andy Andrews 7/December/1995 12:30am >>> Hi, Sorry to post this here, but how do I remove myself from this list ? Also, is there an equivalent newsgroup I can look at ? Thanks -- Come to the edge, He said. They said, we are afraid. Come to the edge, He said. They came. He pushed them ... and they flew. --Guillaume Apollinaire Andy Andrews andya@sgi.com From firewalls-owner Wed Dec 6 19:10:45 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA23409 for firewalls-outgoing; Wed, 6 Dec 1995 16:24:31 -0800 (PST) Received: from altair.ci.umoncton.ca (altair.ci.umoncton.ca [139.103.2.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id QAA23404 for ; Wed, 6 Dec 1995 16:24:26 -0800 (PST) Received: from eve.info.umoncton.ca by altair.ci.umoncton.ca with SMTP (1.38.193.5/16.2) id AA01038; Wed, 6 Dec 1995 20:25:22 -0400 Received: by eve (5.x/SMI-SVR4) id AA03168; Wed, 6 Dec 1995 20:31:16 -0400 Date: Wed, 6 Dec 1995 20:27:57 -0400 (AST) From: Mustapha Obeid - Network Security Analyst Subject: Re: How do I remove myself from this list To: Andy Andrews Cc: firewalls@GreatCircle.com In-Reply-To: <9512060830.ZM2498@aussie.clubfed.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Wed, 6 Dec 1995, Andy Andrews wrote: > Hi, > Sorry to post this here, but how do I remove myself from this list ? > [...] If you ever want to remove yourself from this mailing list, you can send mail to "Majordomo@GreatCircle.COM" with the following command in the BODY of your email message: unsubscribe firewalls Andy Andrews Mustapha =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= /\ =-=-=-=-=- _ _ _ __ _ _ _ _ / \ / / / | \ / / \ / | \ / \ / | | | | | \ __ | / \ / | | | | | \ | / = = = = = = = \ / | | | | | / | | / \ ___/ | | \__ \____/ \_ _ / __|/_ \ /*\ _ _ _ /OOOOO\ _ _ _ /\ / _ \ _ _ _ _ \ IOOOOOI / / \ / \ /| / \ | / | \ | IIIII | | / \ / | | _ /_ / | |=IIIII=| | _ _ _ _ / \ | | \ | | | | / = = = = = = = \ \ | \ | | | | / \ | \ | / \ \_ _ _ _/ \| \__ __|__ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From firewalls-owner Wed Dec 6 19:19:03 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id SAA26906 for firewalls-outgoing; Wed, 6 Dec 1995 18:03:16 -0800 (PST) Received: from gatekeep.genmagic.com (gatekeep.genmagic.com [192.216.16.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id SAA26899 for ; Wed, 6 Dec 1995 18:03:11 -0800 (PST) Received: from (genmagic.genmagic.com [10.1.4.12]) by gatekeep.genmagic.com (8.6.9/8.6.9) with SMTP id RAA04906; Wed, 6 Dec 1995 17:59:03 -0800 Received: from abulafia.genmagic.com by genmagic (4.1/SMI-4.1/JBS) id AA09426; Wed, 6 Dec 95 17:58:32 PST Received: by abulafia.genmagic.com (940816.SGI.8.6.9/930416.SGI) id RAA12718; Wed, 6 Dec 1995 17:58:31 -0800 Date: Wed, 6 Dec 1995 17:58:31 -0800 From: jet@abulafia.genmagic.com (J. Eric Townsend) Message-Id: <199512070158.RAA12718@abulafia.genmagic.com> To: sedayao@argus.intel.com (Jeffrey C. Sedayao) Cc: mibarra@galois.dgaesc.unam.mx (Luis M Ibarra), firewalls@GreatCircle.COM Subject: Randal Schwartz (was Re: Small Demo scanner required.) In-Reply-To: <199512070038.QAA06034@argus.intel.com> References: <199512070038.QAA06034@argus.intel.com> Sender: firewalls-owner@GreatCircle.COM Precedence: bulk "sedayao" == Jeffrey C. Sedayao writes: sedayao> He is a guy with poor judgment who puts holes in your sedayao> firewalls when you aren't looking (or are too trusting). The popular press claimed he *pointed out* holes in firewalls. From firewalls-owner Wed Dec 6 19:54:20 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id TAA00383 for firewalls-outgoing; Wed, 6 Dec 1995 19:29:43 -0800 (PST) Received: from switchblade.iwi.com (switchblade.iwi.com [137.39.156.214]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id TAA00360 for ; Wed, 6 Dec 1995 19:29:31 -0800 (PST) Received: (from mjr@localhost) by switchblade.iwi.com (8.6.9/8.6.9) id WAA05922; Wed, 6 Dec 1995 22:29:39 -0500 From: "Marcus J. Ranum" Message-Id: <199512070329.WAA05922@switchblade.iwi.com> Subject: Re: selection criteria? To: shaver@neon.ingenia.com (Mike Shaver) Date: Wed, 6 Dec 1995 22:29:39 -0500 (EST) Cc: mjr@iwi.com, firewalls@GreatCircle.COM In-Reply-To: <199512061100.GAA22937@neon.ingenia.com> from "Mike Shaver" at Dec 6, 95 06:00:12 am Reply-To: mjr@iwi.com Organization: Information Warehouse! Inc, Baltimore, MD URL: mjr's web page Phone: 410-889-8569 Coredump: Infocalypse Now!!! X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Mike Shaver writes: >I'm beginning to feel a little lonely, but am I _really_ the only one >who sees security as a feature? I do!!! Security is a feature (almost a side-effect) of a well designed system. But one of the important things about security is that you have to be able to make MONEY off it. Vendors, at least in the UNIX space, would rather spend their R&D $$ making cool new chips, better graphics, faster disks, and cheaper boxes, than security. Because they lose money on security and they make money on faster disks, etc. This is yet another of the ways in which I believe the orange book has set back computer security's evolution: by making security a severe *expense* in the development cycle, it has done more than any other single thing to convince the vendors that security is something to stay the hell away from. In order to reverse the trend, we (the amalgamated union of security dweebs local #1024) need to position security as an enabling technology. It's hard. It means telling people, "Hey! That cool thing you want to do? You couldn't do that unless the system supported these basic security services" or whatever. The brightest raw of sunshine I've seen for a while is Sun's success positioning Java as a bitchin' cool thing and that SECURITY is part of the bitchin' coolness of it. The fact that they accomplished a market sell on that fact is good news; it means that people are learning to ask for systems that are more than spit and glue and duct tape. mjr. From firewalls-owner Wed Dec 6 20:24:20 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA02442 for firewalls-outgoing; Wed, 6 Dec 1995 20:09:19 -0800 (PST) Received: from netcom6.netcom.com (netcom6.netcom.com [192.100.81.114]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id UAA02437 for ; Wed, 6 Dec 1995 20:09:16 -0800 (PST) Received: by netcom6.netcom.com (8.6.12/Netcom) id UAA28352; Wed, 6 Dec 1995 20:08:27 -0800 From: okuyama@netcom.com (Darin Okuyama) Message-Id: <199512070408.UAA28352@netcom6.netcom.com> Subject: "-dest" option of http-gw To: firewalls@greatcircle.com (Firewall Mailing List) Date: Wed, 6 Dec 1995 20:08:27 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I am using the patched version of "http-gw" (1.4) and I am trying to use the "-dest" feature to block access back into the protected internal subnets. I tried: http-gw: -permit ________ -dest !_________ -log all | | | doesn't like this hidden to protect the innocent I noticed anytime I used "!", the user was completely blocked. Even when I tried to block localhost ("!127.0.0.1"), it didn't work. Is this a bug? ---Darin Okuyama From firewalls-owner Wed Dec 6 20:54:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA03266 for firewalls-outgoing; Wed, 6 Dec 1995 20:35:22 -0800 (PST) Received: from grunthos.pscwa.psca.com (grunthos.pscwa.psca.com [199.99.162.42]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id UAA03261 for ; Wed, 6 Dec 1995 20:35:17 -0800 (PST) Received: (from iyengar@localhost) by grunthos.pscwa.psca.com (8.6.11/8.6.9) id UAA04756; Wed, 6 Dec 1995 20:34:11 -0800 Date: Wed, 6 Dec 1995 20:34:11 -0800 From: Manu Iyengar Message-Id: <199512070434.UAA04756@grunthos.pscwa.psca.com> To: sedayao@argus.intel.com (Jeffrey C. Sedayao) Cc: mibarra@galois.dgaesc.unam.mx (Luis M Ibarra), firewalls@GreatCircle.COM Subject: Randal Schwartz (was Re: Small Demo scanner required.) In-Reply-To: <199512070038.QAA06034@argus.intel.com> References: <199512070038.QAA06034@argus.intel.com> Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Jeffrey C. Sedayao writes: | > On Wed, 6 Dec 1995, =?ISO-8859-1?Q?Kristian_K=F6hntopp?= wrote: | > Sorry for be such an ignorant (this maybe is off the point), but... | > Who is Randal Schwartz? and, what hapend to him? | | He is a guy with poor judgment who puts holes in your firewalls when you | aren't looking (or are too trusting). See http://www.usa1.com/fors/. Intel sycophants/minions, this is _firewalls_, not the place for personal opinions about Randal Schwartz. 'nuff said. -mi From firewalls-owner Wed Dec 6 21:24:20 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA04572 for firewalls-outgoing; Wed, 6 Dec 1995 21:13:35 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.235.77]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id VAA04565 for ; Wed, 6 Dec 1995 21:13:31 -0800 (PST) Received: from pferguso-pc.cisco.com (c4robo6.cisco.com [171.68.13.76]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id VAA19057; Wed, 6 Dec 1995 21:14:10 -0800 Message-Id: <199512070514.VAA19057@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Dec 1995 00:14:27 -0500 To: awilson@netsystech.com (Anne Wilson - Ext 508) From: Paul Ferguson Subject: Re: What is "NetsysIXA" ? Cc: firewalls@GreatCircle.COM, shuzo@yk.rim.or.jp Sender: firewalls-owner@GreatCircle.COM Precedence: bulk For all of the good friends that I have within this list, and the balance of levity with the professionals therein, its strictly a matter for the participants. Glad to disuss, since it may affect global issues. - paul At 06:00 PM 12/6/95 -0800, Anne Wilson - Ext 508 wrote: >Well, we are Netsys Technologies Inc, but we do network validation >and planning tools for Cisco router networks - you can use the >simulation software to validate the access lists on your router, >but we don't call it "NetsysIXA" .... > >regards > >Anne CM Wilson > >http://www.netsystech.com > > > From firewalls-owner Wed Dec 6 21:30:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA03297 for firewalls-outgoing; Wed, 6 Dec 1995 20:36:00 -0800 (PST) Received: from mimos.my (mimos.my [192.228.128.18]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id UAA03288 for ; Wed, 6 Dec 1995 20:35:53 -0800 (PST) Received: from ms.mimos.my (ms.mimos.my [192.228.129.33]) by mimos.my (8.7.1/8.7.1) with SMTP id MAA00633; Thu, 7 Dec 1995 12:36:49 +0800 (MYT) Received: by ms.mimos.my (5.64/7.0) id AA00542; Thu, 7 Dec 95 12:36:48 +0800 Date: Thu, 7 Dec 1995 12:36:47 +0800 From: Lee Hooi Teck To: firewalls@greatcircle.com Cc: teck@mimos.MY Subject: Re: Tacacs+ or Radius, that is the question. In-Reply-To: <199512061819.SAA12870@global.globale.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Wed, 6 Dec 1995, Eric Caron wrote: [stuff deleted] > similar functionnalities. If I am not wrong, Tacacs+ is more a Cisco thing > whereas an implementation of Radius is distributed by Livingston and MIT. > If I am still not wrong, both are about to get be IETF certified. Does > anyone know which one has a better chance of being a "de facto" standard? > Furthermore, if the access server we purchase support both protocols, which > one should we prioritize? I currently face a problem of integrate these two portocols. We have Ascend product that use RADIUS and CISCO products that use tacacs+. Is there anyway that I can manage these two set of products using just one system? Your help is appreciated. Cheers, teck MIMOS,Malaysia From firewalls-owner Wed Dec 6 21:54:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA06195 for firewalls-outgoing; Wed, 6 Dec 1995 21:49:34 -0800 (PST) Received: from dvlp1.lioninc.com (dvlp1_ppp0.missi.com [204.188.54.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id VAA06190 for ; Wed, 6 Dec 1995 21:49:29 -0800 (PST) Date: Wed, 6 Dec 1995 21:49:29 -0800 (PST) Received: from dvlp_pc1.lioninc.com by dvlp1.lioninc.com id aa07393; 6 Dec 95 21:50 PST X-Sender: jpilley@dvlp1 X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@greatcircle.com From: John Pilley Subject: Mathematical Proof of RSA Encryption Message-ID: <9512062150.aa07393@dvlp1.lioninc.com> Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Ladies and Gentlemen: The asynchronous scheme of encryption/decryption invented by Rivest, Shamir & Adleman involves the use of multiplicative inverses, a modulus and a public and secret key chosen/derived from the primes whose product makes up the modulus. Would one of you good people point me towards a proof(?), derivation(?), explanation(?) showing (Mathematically) how it works? Thanks! John Pilley at InfoSystems Inc. (509) 328-9108 From firewalls-owner Wed Dec 6 22:24:19 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA06229 for firewalls-outgoing; Wed, 6 Dec 1995 21:50:32 -0800 (PST) Received: from SanFrancisco01.POP.InterNex.Net (SanFrancisco01.POP.InterNex.Net [205.158.3.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id VAA06224 for ; Wed, 6 Dec 1995 21:50:28 -0800 (PST) Received: from Anthros.Com ([205.158.235.130]) by SanFrancisco01.POP.InterNex.Net (post.office MTA v1.7 ID# 0-11028) with SMTP id AAA8089; Wed, 6 Dec 1995 21:52:06 -0800 Received: from phoebe.Anthros.Com by Anthros.Com (5.0/SMI-SVR4) id AA08713; Wed, 6 Dec 1995 21:49:41 -0800 Received: by phoebe.Anthros.Com (5.x/SMI-SVR4) id AA02016; Wed, 6 Dec 1995 21:45:42 -0800 Date: Wed, 6 Dec 1995 21:45:42 -0800 From: daemeonr@Anthros.Com@Anthros.Com Message-Id: <9512070545.AA02016@phoebe.Anthros.Com> To: mibarra@galois.dgaesc.unam.mx, sedayao@argus.intel.com Subject: Re: Randal Schwartz (was Re: Small Demo scanner required.) Cc: firewalls@greatcircle.com X-Sun-Charset: US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk => From firewalls-owner@GreatCircle.COM Wed Dec 6 19:03 PST 1995 => From: sedayao@argus.intel.com (Jeffrey C. Sedayao) => Subject: Randal Schwartz (was Re: Small Demo scanner required.) => To: mibarra@galois.dgaesc.unam.mx (Luis M Ibarra) => Date: Wed, 6 Dec 95 16:38:11 PST => Cc: firewalls@greatcircle.com => Mime-Version: 1.0 => Sender: firewalls-owner@GreatCircle.COM => Content-Type: text => => > On Wed, 6 Dec 1995, =?ISO-8859-1?Q?Kristian_K=F6hntopp?= wrote: => > > *get* *permission* to do so. You all remember what happened to => > > Randal Schwartz, don't you? => => > Sorry for be such an ignorant (this maybe is off the point), but... => > Who is Randal Schwartz? and, what hapend to him? => => He is a guy with poor judgment who puts holes in your firewalls when you => aren't looking (or are too trusting). Bullshit, he was a damn fool, but your statement above implies that he was also evil. "Never ascribe to foresight that which can adequately be explained by stupidity" (I know I blew the quote, and no, its not a corrolary to Occam's Razor - or is it?) If you want to know who Randal Schwartz is, go look at the name of the author(s) on O'Reilly & Assoc.'s "Programming Perl" and "Learning Perl", tell Intel to kiss your ass, and buy Cyrix or equiv. Daemeon Reiydelle From firewalls-owner Wed Dec 6 22:26:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA05232 for firewalls-outgoing; Wed, 6 Dec 1995 21:32:59 -0800 (PST) Received: from wabash.iac.net (wabash.iac.net [198.180.60.138]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id VAA05227 for ; Wed, 6 Dec 1995 21:32:54 -0800 (PST) Received: by wabash.iac.net id AAA26127; Thu, 7 Dec 1995 00:33:30 -0500 Date: Thu, 7 Dec 1995 00:33:29 -0500 (EST) From: Carl Jolley To: nokie@eskimo.com cc: firewalls@GreatCircle.COM Subject: Re: Staffing Requirements In-Reply-To: <199512060852.AAA07750@mail.eskimo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I don't see how it would be possible to provide a semi-accurate answer to your question. In my shop, it usually takes 12-15 man-hours per week to do the maintenance and support tasks for our firewall. It is not a full-time job. In your situation, whether it would take more or less time is dependant on several factors. These include: the level and volume of Internet activity, the mix of types of Internet activity (e.g. is it mostly web, mostly e-mail, is it primarily client access or do you have any servers that are accessable from the Internet, what authenication tools are being used), the skill level of the person/persons doing the tasks, the availability and use of software tools. All that being said, probably the best way to figure out your time requirement is to measure the amount of time actually being used over some defined period of time and then armed with that information, have the person with the most knowledge about firewall support functions in your shop make a judgement as to whether there are other factors which would tend to make the number lower or higher and if so by how much. After all, it will only be an estimate since no one has a perfect knowledge of the future. **** cjolley@iac.net **** All opinions are my own and not necessarily those of my employer **** On Wed, 6 Dec 1995 nokie@eskimo.com wrote: > One of the divisions of the company I work for has a permanent connection to the > Internet secured by a Tis Toolkit and a Livingston router doing packet > filtering. Since the connection at this division is of limited bandwidth (56k > at present), over the past year or so some 40 to 50 individuals around the > company (nationwide, but primarily at our central location) have obtained > individual accounts with local ISPs in order to get access. These users are > primarily using Spry's Internet in a Box, but there are also some NT users, OS/2 > users, and a couple of Unix machines as well. Since this growth has not been > managed centrally, and we have (also in the last year or so) finished building a > private internet connecting most of our domestic sites, we are concerned about > the risks that these unsecured dial-up connections pose. > > Within the month, the division with the permanent connection will be upgrading > to a T1 which we feel is adequate to meet the needs of the corporation for > Internet access. We plan to move the serial users to connecting via their lan > connections using the bandwidth and the firewall at the division with the > permanent connection. > > My boss (actually my bosses bosses boss, but who's counting) has asked me to > determine the staffing requirements for maintaining and monitoring the firewall. > Our tendency has been to add function without adding headcount; the techs that > are involved in this project feel that this is not an occasion where that is > practical due to the amount of time and effort involved in monitoring logs, etc. > What is the general consensus on the amount of time and effort involved in these > tasks? > > David Nichols -- on my own dime! > > From firewalls-owner Wed Dec 6 22:54:20 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id WAA07933 for firewalls-outgoing; Wed, 6 Dec 1995 22:35:01 -0800 (PST) Received: from wabash.iac.net (wabash.iac.net [198.180.60.138]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id WAA07909 for ; Wed, 6 Dec 1995 22:34:54 -0800 (PST) Received: by wabash.iac.net id BAA26356; Thu, 7 Dec 1995 01:35:11 -0500 Date: Thu, 7 Dec 1995 01:35:10 -0500 (EST) From: Carl Jolley To: Lee Hooi Teck cc: firewalls@GreatCircle.COM, teck@mimos.MY Subject: Re: Tacacs+ or Radius, that is the question. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Cisco has announced future support for Radius. If I recall correctly they have ported Radius to run under IOS and the first product will be available on one of the 10xx models. Paul, can you shed some light on this? **** cjolley@iac.net **** All opinions are my own and not necessarily those of my employer **** On Thu, 7 Dec 1995, Lee Hooi Teck wrote: > > > On Wed, 6 Dec 1995, Eric Caron wrote: > > [stuff deleted] > > similar functionnalities. If I am not wrong, Tacacs+ is more a Cisco thing > > whereas an implementation of Radius is distributed by Livingston and MIT. > > If I am still not wrong, both are about to get be IETF certified. Does > > anyone know which one has a better chance of being a "de facto" standard? > > Furthermore, if the access server we purchase support both protocols, which > > one should we prioritize? > > I currently face a problem of integrate these two portocols. We have > Ascend product that use RADIUS and CISCO products that use tacacs+. Is > there anyway that I can manage these two set of products using just one > system? > > Your help is appreciated. > > Cheers, > teck > MIMOS,Malaysia > From firewalls-owner Thu Dec 7 00:09:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id XAA10542 for firewalls-outgoing; Wed, 6 Dec 1995 23:51:29 -0800 (PST) Received: from desiree.teleport.com (desiree.teleport.com [192.108.254.21]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id XAA10537 for ; Wed, 6 Dec 1995 23:51:25 -0800 (PST) Received: from claudia.teleport.com (claudia.teleport.com [192.108.254.4]) by desiree.teleport.com (8.6.12/8.6.9) with ESMTP id XAA06261; Wed, 6 Dec 1995 23:52:23 -0800 Received: (darrell@localhost) by claudia.teleport.com (8.6.12/8.6.12) id XAA07766; Wed, 6 Dec 1995 23:51:57 -0800 Date: Wed, 6 Dec 1995 23:51:56 -0800 (PST) From: Darrell Fuhriman To: "Jeffrey C. Sedayao" cc: firewalls@greatcircle.com Subject: Re: Randal Schwartz (was Re: Small Demo scanner required.) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Wed, 6 Dec 1995, Jeffrey C. Sedayao wrote: > > Who is Randal Schwartz? and, what hapend to him? > > He is a guy with poor judgment who puts holes in your firewalls when you > aren't looking (or are too trusting). And then gets taken to court and prosecuted over it. (By Jefferey's employer.) The full story is available at http://www.usa1.com/fors Darrell Fuhriman Teleport System Administration From firewalls-owner Thu Dec 7 00:54:20 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id AAA11954 for firewalls-outgoing; Thu, 7 Dec 1995 00:42:42 -0800 (PST) Received: from crc.u-strasbg.fr (crc.u-strasbg.fr [130.79.200.20]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id AAA11949 for ; Thu, 7 Dec 1995 00:42:19 -0800 (PST) Received: from crc (localhost [127.0.0.1]) by crc.u-strasbg.fr (8.6.11/8.6.9) with SMTP id JAA09189 for ; Thu, 7 Dec 1995 09:38:12 +0100 Message-ID: <30C6A7F3.3B3C@crc-u.strasbg.fr> Date: Thu, 07 Dec 1995 09:38:12 +0100 From: Laurent Balzinger - Centre Reseau Communication - Universite Louis Pasteur Organization: Universite Louis Pasteur Centre Reseau Communication X-Mailer: Mozilla 2.0b3 (X11; I; SunOS 5.4 sun4m) MIME-Version: 1.0 To: firewalls@GreatCircle.COM Subject: TIS config docs & tools Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk HI FWG Please forgive my ignorance ! I project to build a TIS fw, dual home GW based. ______ SN1 IN ------|__TIS_|-------(Cisco router)-- Internet Applt/IPX/IP | ______ | Backbone SN2 IN ------|_TIS__|--------(Cisco router) | | other subnet with no logical link SN1/SN2 I have some claims : - Is there a complete doc for netperm tables mgt. - does anybody know a (free or other) tool that permit IPX and appletalk to be "tunnelled" (beetween GW )thru IP by UNX appl. (an other way to "virtualize" the corporate net) - How can I know what is my Inboard/Outboard card inside TIS ? - How can i control DNS without handling udp in my GW ? - Especially for Paul Ferguson (Hi !). Do you know a doc which details in depth the last IOS acl capabilities. Thanks to everybody for suggestions and info. Laurent From firewalls-owner Thu Dec 7 01:24:20 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id BAA13166 for firewalls-outgoing; Thu, 7 Dec 1995 01:16:01 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id BAA13147 for ; Thu, 7 Dec 1995 01:15:52 -0800 (PST) Message-Id: <199512070915.BAA13147@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA255457804; Thu, 7 Dec 1995 20:16:44 +1100 From: Darren Reed Subject: Re: chroot/setuid vs type enforcement To: smith@sctc.com (Rick Smith) Date: Thu, 7 Dec 1995 20:16:44 +1100 (EDT) Cc: Firewalls@GreatCircle.COM (Firewalls Mailing List) In-Reply-To: <199512061906.NAA05993@shade.sctc.com> from "Rick Smith" at Dec 6, 95 01:06:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In some mail from Rick Smith, sie said: > > Now, I know we can trot out another bandaid to fix mknod(), but don't > we have a pattern here? This is beginning to look like the problem of > keeping naughty users from achieving root -- there's always one more > hole hidden under some subdirectory or an unexpectedly transitive > trust relationship. This comes from not having a set of mandatory > protection objectives *up* *front* and designing to achieve them. What breaks if suser() _always_ fails after chroot() is successfully called ? What breaks that can't be fixed in some other way ? I'm not 100% on this, but I think even root loses a lot of privs (all ?). Is this acceptable for ftp (for example) ? I haven't thought much about it nor tried it out yet... darren From firewalls-owner Thu Dec 7 01:54:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id BAA13782 for firewalls-outgoing; Thu, 7 Dec 1995 01:33:43 -0800 (PST) Received: from NUki (nuki.netuse.de [193.98.110.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id BAA13770 for ; Thu, 7 Dec 1995 01:33:30 -0800 (PST) Received: by Mail.NetUSE.de (SMail3.1.28.1 #2) ID m0tNcmT-0009AgC: Thu, 7 Dec 95 10:38 MET Received: by white.schulung.netuse.de (Smail3.1.29.0 #2) id m0tNawx-0008vCC; Thu, 7 Dec 95 08:41 MET Received: from GATEWAY by white.schulung.netuse.de with netnews for firewalls@greatcircle.com (firewalls@greatcircle.com) To: firewalls@greatcircle.com Date: Thu, 7 Dec 1995 07:39:50 GMT From: kris@schulung.netuse.de (=?ISO-8859-1?Q?Kristian_K=F6hntopp?=) Message-ID: Organization: =?ISO-8859-1?Q?entf=E4llt?= References: <199512062155.NAA17320@miles.greatcircle.com> Subject: Re: Small Demo scanner required. Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Firewalls@GreatCircle.COM writes: > Sorry for be such an ignorant (this maybe is off the point), but... > Who is Randal Schwartz? and, what hapend to him? Randal Schwartz is best known for his work on Perl, a very useful interpreted language that was originally intended for pattern matching and report generation, but now goes far beyond that. Randal was working for Intel as a freelance consultant and was running crack on some password files of Intel on Intels machines. Intel was not glad about this and sued Randal, who is now conviced and has spend a not so small fortune for his defense. See his homepage at http://www.teleport.com/~merlyn/ for his side of the story. Please do not discuss this topic on firewalls. A special mailing list, fors-discuss@teleport.com (Friends of Randal Schwartz) has been set up for this topic. Subscription information for this list should be available from Randals Homepage, too. The point I was going to make is: Don't test other peoples security to do them a favor. It's not worth it. They might sue you and you will lose. Even doorknob twisting should be done only with the express written permission of the targets site admin. Kristian -- Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897 "Z-Netz? Who the fuck is Z-Netz?" -- jop@informatik.uni-kiel.d400.de (Joerg Pechau) in d.t.b From firewalls-owner Thu Dec 7 02:28:55 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA14714 for firewalls-outgoing; Thu, 7 Dec 1995 02:04:14 -0800 (PST) Received: from Norway.EU.net (nic.eunet.no [193.71.1.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id CAA14701 for ; Thu, 7 Dec 1995 02:03:46 -0800 (PST) Received: from betsy.texcel.no by Norway.EU.net with SMTP id AA10463 (5.65c/IDA-1.4.4/EUnet/NO for ); Thu, 7 Dec 1995 11:04:17 +0100 Received: from texcel.no by betsy.texcel.no (4.1/SMI-4.1) id AA02413; Thu, 7 Dec 95 11:12:39 +0100 Received: by texcel.no.texcel.no (4.1/SMI-4.1) id AA00302; Thu, 7 Dec 95 09:52:07 GMT Date: Thu, 7 Dec 95 09:52:07 GMT From: mdr@texcel.no (Mark Robinson) Message-Id: <9512070952.AA00302@texcel.no.texcel.no> To: Firewalls@GreatCircle.COM Subject: RE: Randall Schwartz Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > From: sedayao@argus.intel.com (Jeffrey C. Sedayao) > Date: Wed, 6 Dec 95 16:38:11 PST > Subject: Randal Schwartz (was Re: Small Demo scanner required.) > > > On Wed, 6 Dec 1995, =?ISO-8859-1?Q?Kristian_K=F6hntopp?= wrote: > > > *get* *permission* to do so. You all remember what happened to > > > Randal Schwartz, don't you? > > > Sorry for be such an ignorant (this maybe is off the point), but... > > Who is Randal Schwartz? and, what hapend to him? > > He is a guy with poor judgment who puts holes in your firewalls when you > aren't looking (or are too trusting). he did show poor judgement - he thought he could be helpful to Intel. Intel "broke a butterfly on a wheel". mark > > > -- > > Luis M. Ibarra > > UNAM, DGAE. > > - -- > Jeff Sedayao > Intel Corporation > sedayao@argus.intel.com > From firewalls-owner Thu Dec 7 02:54:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA15628 for firewalls-outgoing; Thu, 7 Dec 1995 02:30:18 -0800 (PST) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id CAA15609 for ; Thu, 7 Dec 1995 02:30:03 -0800 (PST) From: mail06823@pop.net Received: from alterdial.UU.NET by relay5.UU.NET with SMTP id QQztbm21424; Thu, 7 Dec 1995 05:31:00 -0500 (EST) Received: from 205.230.245.98 by alterdial.UU.NET with SMTP id QQztbm03703; Thu, 7 Dec 1995 05:30:59 -0500 Date: Thu, 7 Dec 1995 05:30:59 -0500 Message-Id: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Outbound Authentication To: firewalls@greatcircle.com X-Mailer: SPRY Mail Version: 04.00.06.17 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hi, My company's net security is relatively weak, and we are currently going through Firewalling & all of that good stuff. We have a large dialup community that needs access to our internal network, and to the Internet. We are handling this with the multi-homed configuration. The issue is the following. We as security think we should have users authenticate while dialing up to get to either the internal net or the \ Internet. The primary rationale is that the logging on the remote access server product is weak, and that static passwords are weak. It also concedes that every environment has "insider risk", and we need some way of knowing who is doing what....even if they are just going out to the Internet. Any thoughts / comments? Anyone gone through this debate? Thanks in advance. From firewalls-owner Thu Dec 7 03:24:20 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA15371 for firewalls-outgoing; Thu, 7 Dec 1995 02:21:59 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id CAA15351 for ; Thu, 7 Dec 1995 02:21:44 -0800 (PST) Message-Id: <199512071021.CAA15351@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA268531746; Thu, 7 Dec 1995 21:22:26 +1100 From: Darren Reed Subject: Re: TokenRing Firewalls To: rpm@holstein.com (Rob MacDonald) Date: Thu, 7 Dec 1995 21:22:26 +1100 (EDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <199512051912.LAA22943@miles.greatcircle.com> from "Rob MacDonald" at Dec 5, 95 02:12:50 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In some mail from Rob MacDonald, sie said: > > > Another newbie joins the list. > > I have recently joined this group in hopes of seeing how to protect our > network(s). In all the conversations I have been following, I have only > seen refernces to Ethernet. I am wondering if there are any TokenRing > based firewall packages? We are mostly TR with some Ethernet. We do have > a couple of Cisco routers (2500 & 4000's). We are TR attached to our service > provider thru the 2500. Any comments would be appreciated. The link layer (Token Ring/Ethernet/PPP) should not make any difference to your firewall. If you go for the proxy firewall, it makes 0 difference, only some packet filter types might have trouble if they've only been implemented to support Ethernet frames. ie it won't be of concern to your ciscos if you include them as part of your firewall. The only box that I could imagine having some trouble would be SunScreen (or other NATs) which don't plug into Token Ring (?). darren From firewalls-owner Thu Dec 7 03:54:26 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id DAA17856 for firewalls-outgoing; Thu, 7 Dec 1995 03:34:15 -0800 (PST) Received: from eagle.idshq.com (eagle.idshq.com [199.100.93.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id DAA17851 for ; Thu, 7 Dec 1995 03:34:07 -0800 (PST) From: Mark_Podracky@idshq.com Received: from smtpgtwy.idshq.com (smtpgtwy.idshq.com [199.100.93.5]) by eagle.idshq.com (8.6.10/8.6.10) with SMTP id CAA10183; Thu, 7 Dec 1995 02:26:36 -0500 Received: from cc:Mail by smtpgtwy.idshq.com id AA818350480 Thu, 07 Dec 95 07:34:40 EST Date: Thu, 07 Dec 95 07:34:40 EST Message-Id: <9511078183.AA818350480@smtpgtwy.idshq.com> To: firewalls@greatcircle.com, Kenneth Smith Subject: Re: NT Security and NTFS Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Ken, I have been working with NTFS for a couple of years now. The manner in which the file system is organized makes it difficult (not necessaily impossible since nothing is impossible) to access the file system by booting with another operating system/file system co-installed or even not native to the machine (e.g., a DOS boot floppy, etc.) I suggest you get a copy of the NT Resource kit and the C2 manuals for NT 3.51. These go into more detail concerning the operating system and NTFS file system than I can go into here. Mark Podracky Sr. INFOSEC Specialist Integrated Data Systems 14170 Newbrook Drive, Suite 201 Chantilly, VA 22021-2223 ______________________________ Reply Separator _________________________________ Subject: NT Security and NTFS Author: Kenneth Smith at ccSMTP Date: 12/6/95 3:50 PM Questions about NT security have been tossed around quite a bit lately, but I have a new one to add to the pot. One of the claims which NT makes to security is its NTFS file system, which unlike FAT supports permissions natively. It is, for instance, a required element of NT's C2 configuration. But as I understand it . . . wouldn't it be possible to write or obtain an NTFS file system driver for some alternate OS which supports installable file systems (i.e., Windows 95, Linux)? If this is the case, wouldn't this mean that booting to or installing that OS on anotherwise supposedly secure system would grant the user unrestricted access to the file system? I would imagine that some enterprising individual could even come up with a way to boot the file system and a simple command-line interface off of a floppy. I know that this question presupposes physical access to the machine in question, and if that happens there are any number of possible back-doors, but it still strikes me as a rather large loophole. Comments? Ken Smith Independent National Mortgage From firewalls-owner Thu Dec 7 04:24:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id DAA18763 for firewalls-outgoing; Thu, 7 Dec 1995 03:58:51 -0800 (PST) Received: from molhub.mol.net.my (molhub.mol.net.my [202.190.128.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id DAA18757 for ; Thu, 7 Dec 1995 03:58:41 -0800 (PST) From: jeknaggs@molhub.mol.net.my Received: by molhub.mol.net.my; Thu, 7 Dec 95 20:01:13 +0800 Date: Thu, 7 Dec 1995 20:01:13 +0800 (SGT) To: firewalls@GreatCircle.COM Subject: automated ftp (?) script Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Greetings All, I hope someone out there can help out this newbie. I'm looking for a way to automate ftp access to a Unix (Solaris 2.x) server. The method should be able to : 1. specify which server to connect to 2. specify the ftp handshake to connect to the remote ftp server ( regardless of the ftp server used ) 3. specify the actions to be taken after successful connection 4. enable logging of the activation of this automated "program" BTW, could any of u please recommend good, proven-usable, programs which could be used for automating the mirroring process of a Web site's HTML documents / cgi-programs ? The programs should be able to implement the above without compromising security of the local host or the remote ftp server. Additionally, these programs should be able to work thru firewalls. Thanks & regards, PS : Merry Christmas & a Happy New Year. God bless u. ==================================================================== Jeffrey Knaggs - Software Engineer : AIMS Sdn Bhd / Malaysia Online e-mail : jeknaggs@mol.net.my URL : http://www.mol.net.my ==================================================================== From firewalls-owner Thu Dec 7 05:24:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA22340 for firewalls-outgoing; Thu, 7 Dec 1995 05:16:38 -0800 (PST) Received: from relay1gw.alcatel.fr (relay1gw.alcatel.fr [193.104.30.53]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id FAA22333 for ; Thu, 7 Dec 1995 05:16:23 -0800 (PST) Received: from istans.ansf.alcatel.fr by relay1gw.alcatel.fr with SMTP (1.37.109.8/16.2) id AA27675; Thu, 7 Dec 1995 14:17:05 +0200 Received: from AHQP14 ([155.132.120.211]) by istans.ansf.alcatel.fr (4.1/SMI-4.1) id AA05867; Thu, 7 Dec 95 14:19:35 +0100 Message-Id: <9512071319.AA05867@istans.ansf.alcatel.fr> Comments: Authenticated sender is From: "Kare Presttun" Organization: Alcanet International To: Firewalls@GreatCircle.COM Date: Thu, 7 Dec 1995 14:20:16 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Radius and Tacacs+ Reply-To: Kare.Presttun@ansf.alcatel.fr X-Mailer: Pegasus Mail for Windows (v2.01) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > > I currently face a problem of integrate these two portocols. We have > Ascend product that use RADIUS and CISCO products that use tacacs+. Is > there anyway that I can manage these two set of products using just one > system? > > Your help is appreciated. > > Cheers, > teck > MIMOS,Malaysia > Enigma Logic's Safeword Authentication server handles this. Take a look at http://www.safeword.com/ Kare ---------------------------------------------------------- | Kare Presttun Alcanet International | | Tel: +33 1 4058 5614 33, rue Emeriau | | Fax: +33 1 4058 5945 F-75015 Paris | | Kare.Presttun@ansf.alcatel.fr FRANCE | From firewalls-owner Thu Dec 7 05:54:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA22616 for firewalls-outgoing; Thu, 7 Dec 1995 05:23:21 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.235.77]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id FAA22611 for ; Thu, 7 Dec 1995 05:23:18 -0800 (PST) Received: from pferguso-pc.cisco.com (c2robo10.cisco.com [171.68.13.36]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id FAA28478; Thu, 7 Dec 1995 05:23:57 -0800 Message-Id: <199512071323.FAA28478@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Dec 1995 08:24:15 -0500 To: firewalls@GreatCircle.COM From: Paul Ferguson Subject: Re: What is "NetsysIXA" ? Cc: awilson@netsystech.com (Anne Wilson - Ext 508) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk What I *meant* to say, as it appears I was semi-awake when I made this comment, is that the NetSys stuff is pretty neat. :-) Surf over to http://www.netsystech.com and take a look. - paul At 12:14 AM 12/7/95 -0500, Paul Ferguson wrote: >For all of the good friends that I have within this list, and >the balance of levity with the professionals therein, its strictly >a matter for the participants. > >Glad to disuss, since it may affect global issues. > >- paul > > >At 06:00 PM 12/6/95 -0800, Anne Wilson - Ext 508 wrote: > >>Well, we are Netsys Technologies Inc, but we do network validation >>and planning tools for Cisco router networks - you can use the >>simulation software to validate the access lists on your router, >>but we don't call it "NetsysIXA" .... >> >>regards >> >>Anne CM Wilson >> >>http://www.netsystech.com >> >> >> > > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso@cisco.com c i s c o S y s t e m s From firewalls-owner Thu Dec 7 06:24:28 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA24171 for firewalls-outgoing; Thu, 7 Dec 1995 06:05:37 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA24166 for ; Thu, 7 Dec 1995 06:05:32 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id JAA24182; Thu, 7 Dec 1995 09:06:01 -0500 Date: Thu, 7 Dec 1995 09:06:01 -0500 Message-Id: <199512071406.JAA24182@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Rick Smith From: Anton J Aylward Subject: Re: Firewalls for the rest of us (was Re: A1 Systems) Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 14:37 5/12/95 -0600, you wrote: >After the Gulf War the defense establishment here decided they >couldn't wait for trusted OSes on everyones' desktop ....... > [snip] > ....... So, they increased their exposure to attack at >the same time the threat was growing. They traded off the increased >risks against increased operational capabilities. Clausewitz could >have predicted it. I guess this is the reason so many organizations are connecting to the Internet without any firewalling at all. Or are you just baiting MJR and myself over the Napoleon/Clausewitz thing ? --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Thu Dec 7 06:34:32 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA22895 for firewalls-outgoing; Thu, 7 Dec 1995 05:32:34 -0800 (PST) Received: from telxon.mis.telxon.com (TELXON.MIS.TELXON.COM [149.23.2.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id FAA22886 for ; Thu, 7 Dec 1995 05:32:30 -0800 (PST) Received: from sbridg.mis.telxon.com by telxon.mis.telxon.com (5.61/3.1.090690-Telxon Corporation) id AA20200; Thu, 7 Dec 95 08:32:06 -0500 Message-Id: <9512071332.AA20200@telxon.mis.telxon.com> From: jwojn@telxon.mis.telxon.com (Wojno, Jim) Date: Thu, 07 Dec 1995 08:27 EST To: firewalls@greatcircle.com Subject: RE: NT Security and NTFS Sender: firewalls-owner@GreatCircle.COM Precedence: bulk While the scenario you describe below does seem like a large loophole, it is no more so than on most of the OS's I've worked with. On Sun systems, as well as Sequent machines, if a person has the install CD-ROM or tape and has physical access to that machine, they can boot to miniroot. Once done, the filesystem can be mounted and accessed without a password, allowing total access to any and all files. The key to preventing this would be to ensure limited access to the machine in question. Jim Wojno Systems Administrator Telxon Corporation ---------- >Questions about NT security have been tossed around quite a bit lately, but I >have a new one to add to the pot. >One of the claims which NT makes to security is its NTFS file system, which >unlike FAT supports permissions natively. It is, for instance, a required >element of NT's C2 configuration. >But as I understand it . . . wouldn't it be possible to write or obtain an >NTFS file system driver for some alternate OS which supports installable file >systems (i.e., Windows 95, Linux)? If this is the case, wouldn't this mean >that booting to or installing that OS on anotherwise supposedly secure system >would grant the user unrestricted access to the file system? I would imagine >that some enterprising individual could even come up with a way to boot the >file system and a simple command-line interface off of a floppy. >I know that this question presupposes physical access to the machine in >question, and if that happens there are any number of possible back-doors, >but it still strikes me as a rather large loophole. >Comments? >Ken Smith >Independent National Mortgage From firewalls-owner Thu Dec 7 07:31:28 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA25584 for firewalls-outgoing; Thu, 7 Dec 1995 06:55:13 -0800 (PST) Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id GAA25579 for ; Thu, 7 Dec 1995 06:55:06 -0800 (PST) Received: from gaau.ga.mt.np.els-gms.att.net by relay4.UU.NET with SMTP id QQztcd01294; Thu, 7 Dec 1995 09:55:59 -0500 (EST) Date: Thu, 07 Dec 1995 09:53:20 -0500 From: ufpsprod!gmyers@atlml1.attmail.com (MYERS) Received: from atlml1 by attmail; Thu Dec 7 14:55 GMT 1995 Received: from ufpsprod by atlml1; Thu, 7 Dec 1995 09:53 EST Received: from ufps11.ufps by ufps.att.com (4.1/SMI-4.1) id AA29489; Thu, 7 Dec 95 09:53:20 EST Subject: re: list removal To: firewalls@GreatCircle.COM Message-Id: <9512071453.AA29489@ufps.att.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: firewalls-owner@GreatCircle.COM Precedence: bulk } You can check in any time you want, but you can never leave ... Actually, I believe the line is: You can check out any time you like, but you may never leave..... } } > } > Hi, } > Sorry to post this here, but how do I remove myself from this list ? } > Also, is there an equivalent newsgroup I can look at ? } > } > Thanks } > } > } > } > } > -- } > Come to the edge, He said. } > They said, we are afraid. } > Come to the edge, He said. } > They came. } > He pushed them ... and they flew. } > --Guillaume Apollinaire } > } > Andy Andrews } > andya@sgi.com } > } > -- Jon F. Spencer spencerj@rtp.dg.com (uunet!rtp.dg.com!spencerj) Data General Corp. Phone : (919)248-6246 62 T.W. Alexander Dr, MS #119 FAX : (919)248-6108 Research Triangle Park, NC 27709 Office RTP 121/9 Reality is an illusion - perception is what counts. No success can compensate for failure at home. President David O. McKay ***** UCC 1-207 ******** Until later, attmail!gamyers ph 404.810.3250 Geoffrey Myers fax 404.810.2487 floc 6E26, 1200 Peachtree, Promenade II, Atlanta, GA 30309 gamyers@attmail.com geof@denali.is.net eiger@ichange.com From firewalls-owner Thu Dec 7 07:35:27 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA25411 for firewalls-outgoing; Thu, 7 Dec 1995 06:47:26 -0800 (PST) Received: from yeager.nmh.org (YEAGER.NMH.ORG [165.20.13.23]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA25406 for ; Thu, 7 Dec 1995 06:47:23 -0800 (PST) Received: from [165.20.152.43] ([165.20.152.43]) by yeager.nmh.org (8.6.9/8.6.9) with SMTP id IAA17193 for ; Thu, 7 Dec 1995 08:49:51 -0600 X-Sender: cdavidso@yeager.nmh.org Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Dec 1995 08:49:29 -0600 To: Firewalls@GreatCircle.COM From: cdavidso@nmh.org (Clyde Davidson) Subject: More Single SignOn Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I have been reading the exhausting discussion on single sign-on products with some interest. The firewall that I have (Sidewinder) uses Digital Pathways and is about to use LockOUT as well. Yesterday my boss went to a show where they pushed TACACS+ and he was excited. Does anyone here care to make an evaluation and comparison of the above products (and others)? ~~~~~~~~~~~~~~~~~~~~~~~~~~ Clyde Davidson Northwestern Memorial Hospital, Data Security Coordinator, Information Services From firewalls-owner Thu Dec 7 07:38:09 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA21750 for firewalls-outgoing; Thu, 7 Dec 1995 05:05:08 -0800 (PST) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id FAA21744 for ; Thu, 7 Dec 1995 05:05:04 -0800 (PST) Received: from uucp6.UU.NET by relay5.UU.NET with SMTP id QQztbw02868; Thu, 7 Dec 1995 08:06:04 -0500 (EST) Received: from brite.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Thu, 7 Dec 1995 08:06:03 -0500 Received: from usrpc10.wichita.brite.com by brite.wichita.brite.com (5.65/1.35) id AA18290; Thu, 7 Dec 95 08:06:41 -0600 Date: Thu, 7 Dec 95 07:00:10 CST From: Shane T Kinsch Subject: RE: automated ftp (?) script To: uunet!GreatCircle.COM!firewalls@uunet.uu.net, uunet!molhub.mol.net.my!jeknaggs@uunet.uu.net X-Mailer: Chameleon V0.05, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Thu, 7 Dec 1995 20:01:13 +0800 (SGT) uunet!molhub.mol.net.my!jeknaggs wrote: >Greetings All, > I hope someone out there can help out this newbie. I'm looking >for a way to automate ftp access to a Unix (Solaris 2.x) server. The >method should be able to : >1. specify which server to connect to >2. specify the ftp handshake to connect to the remote ftp server > ( regardless of the ftp server used ) >3. specify the actions to be taken after successful connection >4. enable logging of the activation of this automated "program" This will get you started. This is a script that I wrote a long time ago to fetch a file from a remote node... Of course, this was written when I was working for NCR... #!/bin/ksh # # Simple shell script to fetch a file from the given host. # Syntax: getfile ... # # Shane Kinsch (Shane.Kinsch@WichitaKS.NCR.COM) # host=120.243.287.6 directory=/allpcms/skinsch/WORK if [ $# -ne 1 ] then echo "Usage: $0 ..." exit 1 fi ( echo user skinsch echo cd $directory echo hash echo binary for n do echo get $n done echo bye ) | ftp -n -v $host _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Shane T Kinsch BRITE VOICE SYSTEMS, INC. _/ _/ shane.kinsch@brite.com UNIX SYSTEM ADMINISTRATOR _/ _/ Wichita, KS USA VP UNIX ENGINEERING _/ _/ http://www.brite.net "MIME is ok here" _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From firewalls-owner Thu Dec 7 08:02:08 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA25568 for firewalls-outgoing; Thu, 7 Dec 1995 06:54:50 -0800 (PST) Received: from aspensys ([198.77.70.105]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA25563 for ; Thu, 7 Dec 1995 06:54:46 -0800 (PST) Received: from smtpinet.aspensys.com (smtpgate.aspensys.com) by aspensys (5.0/SMI-SVR4) id AA09493; Thu, 7 Dec 1995 09:50:29 +0500 Received: from ccMail by smtpinet.aspensys.com (SMTPLINK V2.10.08) id AA818358951; Thu, 07 Dec 95 10:16:21 EST Date: Thu, 07 Dec 95 10:16:21 EST From: "Jim Meritt" Message-Id: <9511078183.AA818358951@smtpinet.aspensys.com> To: firewalls@GreatCircle.COM, jeknaggs@molhub.mol.net.my Subject: Re: automated ftp (?) script Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I done this with scripts set off by crontab before, and I've seen bbs systems that do it. Check .netrc files used with ftp for gouge. Jim Meritt ______________________________ Reply Separator _________________________________ Subject: automated ftp (?) script Author: jeknaggs@molhub.mol.net.my at SMTPINET Date: 12/7/95 8:21 AM Greetings All, I hope someone out there can help out this newbie. I'm looking for a way to automate ftp access to a Unix (Solaris 2.x) server. The method should be able to : 1. specify which server to connect to 2. specify the ftp handshake to connect to the remote ftp server ( regardless of the ftp server used ) 3. specify the actions to be taken after successful connection 4. enable logging of the activation of this automated "program" BTW, could any of u please recommend good, proven-usable, programs which could be used for automating the mirroring process of a Web site's HTML documents / cgi-programs ? The programs should be able to implement the above without compromising security of the local host or the remote ftp server. Additionally, these programs should be able to work thru firewalls. Thanks & regards, PS : Merry Christmas & a Happy New Year. God bless u. ==================================================================== Jeffrey Knaggs - Software Engineer : AIMS Sdn Bhd / Malaysia Online e-mail : jeknaggs@mol.net.my URL : http://www.mol.net.my ==================================================================== From firewalls-owner Thu Dec 7 08:13:00 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA25506 for firewalls-outgoing; Thu, 7 Dec 1995 06:54:20 -0800 (PST) Received: from Disclosure.COM (di2.disclosure.com [205.156.194.11]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA25501 for ; Thu, 7 Dec 1995 06:54:16 -0800 (PST) Received: by Disclosure.COM (4.1/SMI-4.1) id AA29799; Thu, 7 Dec 95 09:55:20 EST Date: Thu, 7 Dec 1995 09:55:19 -0500 (EST) From: Scott Barman To: Mark_Podracky@idshq.com Cc: firewalls@greatcircle.com, Kenneth Smith Subject: Re: NT Security and NTFS In-Reply-To: <9511078183.AA818350480@smtpgtwy.idshq.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Thu, 7 Dec 1995 Mark_Podracky@idshq.com wrote: > I have been working with NTFS for a couple of years now. The manner in > which the file system is organized makes it difficult (not necessaily > impossible since nothing is impossible) to access the file system by > booting with another operating system/file system co-installed or even > not native to the machine (e.g., a DOS boot floppy, etc.) I suggest > you get a copy of the NT Resource kit and the C2 manuals for NT 3.51. > These go into more detail concerning the operating system and NTFS > file system than I can go into here. > > > Mark Podracky > Sr. INFOSEC Specialist Hmm... and I know someone working on an NTFS driver for FreeBSD. He can mount, read and write NTFS while FreeBSD is running with few problems. Sure, there are some undocumented "features" he has yet to deal with (you mean Microsoft didn't document something about NT? Wow Scott, that's amazing! :-), but he's having no problems accessing that drive. According to my friend, there's little extaordinary about NTFS. In fact, he calls it a modified VMS file system (I wonder why :-). I think we best stop listening to Micro$haft's marketing machine and deal with reality! scott barman -- scott barman DISCLAIMER: I speak to anyone who will listen, scott@disclosure.com and I speak only for myself. barman@ix.netcom.com "I don't know if security explains why the Win95 support Web servers run BSDI 2.0--an Intel-based Unix--rather than Windows NT, which Microsoft insists is the ideal Web software solution. Does Redmond know something we don't know?" -Robert X. Cringely, INFORWORLD, 9/11/95 From firewalls-owner Thu Dec 7 08:30:32 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA28565 for firewalls-outgoing; Thu, 7 Dec 1995 08:20:39 -0800 (PST) Received: from relay1gw.alcatel.fr (relay1gw.alcatel.fr [193.104.30.53]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA28556 for ; Thu, 7 Dec 1995 08:20:23 -0800 (PST) Received: from istans.ansf.alcatel.fr by relay1gw.alcatel.fr with SMTP (1.37.109.8/16.2) id AA02594; Thu, 7 Dec 1995 17:21:02 +0200 Received: from AHQP14 ([155.132.120.211]) by istans.ansf.alcatel.fr (4.1/SMI-4.1) id AA08082; Thu, 7 Dec 95 17:23:32 +0100 Message-Id: <9512071623.AA08082@istans.ansf.alcatel.fr> Comments: Authenticated sender is From: "Kare Presttun" Organization: Alcanet International To: Firewalls@GreatCircle.COM Date: Thu, 7 Dec 1995 17:24:14 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Distributed Systems Security Reply-To: Kare.Presttun@ansf.alcatel.fr X-Mailer: Pegasus Mail for Windows (v2.01) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hi, Those of you interested in Distributed Systems Security and enhancements to Kerberos should take a look at SESAME. Information is available at: http://www.esat.kuleuven.ac.be/cosic/sesame.html SESAME adds to Kerberos : Heterogeneity, sophisticated access control features, scalability of public key systems, better manageability, audit and delegation. Best regards, Kare ---------------------------------------------------------- | Kare Presttun Alcanet International | | Tel: +33 1 4058 5614 33, rue Emeriau | | Fax: +33 1 4058 5945 F-75015 Paris | | Kare.Presttun@ansf.alcatel.fr FRANCE | From firewalls-owner Thu Dec 7 08:54:36 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA26372 for firewalls-outgoing; Thu, 7 Dec 1995 07:19:03 -0800 (PST) Received: from neon.ingenia.com (neon.ingenia.com [205.207.219.29]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA26367 for ; Thu, 7 Dec 1995 07:18:58 -0800 (PST) Received: (from shaver@localhost) by neon.ingenia.com (8.6.12/8.6.9) id KAA06567; Thu, 7 Dec 1995 10:20:58 -0500 From: Mike Shaver Message-Id: <199512071520.KAA06567@neon.ingenia.com> Subject: Re: selection criteria? To: scott@Disclosure.COM (Scott Barman) Date: Thu, 7 Dec 1995 10:20:57 -0500 (EST) Cc: mjr@iwi.com, firewalls@GreatCircle.COM In-Reply-To: from "Scott Barman" at Dec 7, 95 09:39:24 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Thus spake Scott Barman: > > brightest raw of sunshine I've seen for a while is Sun's success > > positioning Java as a bitchin' cool thing and that SECURITY is > > part of the bitchin' coolness of it. The fact that they accomplished > > a market sell on that fact is good news; it means that people are > > learning to ask for systems that are more than spit and glue and > > duct tape. > > Sure... Sun did that AFTER its potential security problems were beaten > up here and on other mailing lists and newsgroups. Yes, I know they put > out their white paper on their security position. But Sun did not start > to advertise it with its security "feature" until AFTER the onslaught > from the union. Again, they were reactive rather than proactive. As long as I've been involved with Java (since March, I guess), security has been a big part of the package. When Netscape got a hold of it, the focus shifted, but they're Netscape... that's the way they work. Your paragraph confuses me... the security of Java was well publicized _long_ before it got taken to task on the lists and groups. The flaws that were found by the Princeton folks were fixed in a later release, obviously, but the _design_ aspect was always there. And it's really nice to see a vendor designing for security rather than just implementing for it, isn't it? > To my knowledge only DEC and IBM have proactive groups (among Unix > vendors) solely concerned with security. Yes, I know DEC was first > (SEAL), but IBM has always been proactive with computing security (on > their mainframes) and now has extended that to their Unix offerings. I thought Sun had a similar group... (And their "Trusted Solaris" product has to mean _something_.) Mike -- #> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation <# #> Ignore the man behind the curtain. <# #> <# #> "And then I realized that it never should have worked in the first <# #> place. Thus, it would not work again until rewritten." --- Anon. <# From firewalls-owner Thu Dec 7 09:01:39 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA28009 for firewalls-outgoing; Thu, 7 Dec 1995 08:05:55 -0800 (PST) Received: from newsgw.mentorg.com (newsgw.mentorg.com [137.202.128.5]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA28004 for ; Thu, 7 Dec 1995 08:05:52 -0800 (PST) Received: from wv.wv.mentorg.com by newsgw.mentorg.com (8.6.4/CF5.22R) id LAA26418; Thu, 7 Dec 1995 11:06:23 -0500 Received: from em-wv03.wv.mentorg.com by wv.wv.mentorg.com (8.6.8.1/CF5.22R) id IAA25977; Thu, 7 Dec 1995 08:06:46 -0800 Received: from shiloh.wv.mentorg.com by em-wv03.wv.mentorg.com (8.6.8.1/CF5.23H) id IAA12385; Thu, 7 Dec 1995 08:07:43 -0800 From: sean_boyle@MENTORG.COM (Sean Boyle x1542) Received: by shiloh.wv.mentorg.com (1.38.193.4/CF3.4) id AA17821; Thu, 7 Dec 1995 08:07:36 -0800 Date: Thu, 7 Dec 1995 08:07:36 -0800 Message-Id: <9512071607.AA17821@shiloh.wv.mentorg.com> Apparently-To: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk LIST From firewalls-owner Thu Dec 7 09:03:30 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA23500 for firewalls-outgoing; Thu, 7 Dec 1995 05:53:11 -0800 (PST) Received: from denver.ssds.com (denver.ssds.com [134.127.16.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id FAA23495 for ; Thu, 7 Dec 1995 05:53:07 -0800 (PST) Received: from freke.ssds.com (rem_den29.ssds.com [134.127.122.29]) by denver.ssds.com (8.6.9/8.6.9.SSDSnet-hub) with SMTP id GAA12246; Thu, 7 Dec 1995 06:52:42 -0700 Message-Id: <2.2b8.32.19951207135039.00c23f04@denver.ssds.com> X-Sender: cds@denver.ssds.com X-Mailer: Windows Eudora Pro Version 2.2b8 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Dec 1995 07:50:39 -0600 To: Garry Garrett From: "Chris Liljenstolpe (Swanson) - SSDS" Subject: Re: Poking a hole in the firewall Cc: "'firewalls list from GreatCircle'" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Greetings, Well, this is the same problem with ftp. You should REALLY look at something more sturdy than router filters. If, for example, you went with a TIS FWTK firewall, you could do a plug GW between the two machines. With a socks firewall, and socksified client (it takes one aditional line in the make file for the application) you could use socks to communicate with your server. Regards, -=Chris At 10:15 AM 12/6/95 PST, the sage, Garry Garrett, uttered these words: (> (>I have a Web server. This web server needs to get some data off (>of another machine, inside my firewall. My programmer wants to write (>his own little home grown TCP/IP application to communicate between (>his program on my web server and his program on my interal machine. (>He tests it internally, and it works fine. He puts his application on the (>web server and I poke a hole in the router and the application does (>not work. (> (>Here's what I've found. I am opening up one TCP port for him to use, (>but the unix function calls that he's using (the only ones he really knows (>of) operate like this: Client calls the server on port X. Server responds (>to Client on port X, giving it a high port number that is available. Client (>calls the server on that high port number to communicate. This allows (>for multiple client programs to be fired off. (> (>My reaction is, hey, I can poke a hole at some known port number for (>your application, but I can't just allow some random port number through (>the router (can I?). His reaction is, hey, I can't just choose the port (>number (>that the client is going to use once it's connected. (> (>How are these things normally accomplished? I need to have my Web (>server serve up data that is on an internal machine. What data I need (>from the internal machine depends upon the search criteria that the Web (>user entered on their form. Is there some range of port numbers that (>connect() and accept() are going to use that it's safe for me to allow (>through my firewall, or better yet, is there a way I can control what port (>number is assigned to the client so that I can only poke holes for the (>clients I expect, etc. The web server and the internal machine are (>both unix boxes. (> (>Am I barking up the wrong tree? Is there a better way to be doing this? (>I've considered a NULL modem cable between the 2 machines, but (>I'm not sure it can handle the load like TCP/IP can. (> (>Garry (>Garry.Garrett@abii.com (> (> -- ( ( | ( Chris Liljenstolpe ) ) (| ), inc. SSDS, Inc; 8400 Normandale Lake Blvd.; Suite 993 business driven Bloomington, MN 55437; technology solutions TEL 612.921.2392 FAX 612.921.2395 Um Yah Yah! From firewalls-owner Thu Dec 7 09:07:14 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA24196 for firewalls-outgoing; Thu, 7 Dec 1995 06:07:21 -0800 (PST) Received: from Disclosure.COM (di2.disclosure.com [205.156.194.11]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA24191 for ; Thu, 7 Dec 1995 06:07:16 -0800 (PST) Received: by Disclosure.COM (4.1/SMI-4.1) id AA29707; Thu, 7 Dec 95 09:09:52 EST Date: Thu, 7 Dec 1995 09:09:52 -0500 (EST) From: Scott Barman To: "Jeffrey C. Sedayao" Cc: Luis M Ibarra , firewalls@greatcircle.com Subject: Re: Randal Schwartz (was Re: Small Demo scanner required.) In-Reply-To: <199512070038.QAA06034@argus.intel.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Wed, 6 Dec 1995, Jeffrey C. Sedayao wrote: > > On Wed, 6 Dec 1995, =?ISO-8859-1?Q?Kristian_K=F6hntopp?= wrote: > > > *get* *permission* to do so. You all remember what happened to > > > Randal Schwartz, don't you? > > > Sorry for be such an ignorant (this maybe is off the point), but... > > Who is Randal Schwartz? and, what hapend to him? > > He is a guy with poor judgment who puts holes in your firewalls when you > aren't looking (or are too trusting). Nothing like the Intel spin. Between them and Micro$loth we had hold back computing another 10 years! > Jeff Sedayao > Intel Corporation > sedayao@argus.intel.com > -- scott barman DISCLAIMER: I speak to anyone who will listen, scott@disclosure.com and I speak only for myself. barman@ix.netcom.com "I don't know if security explains why the Win95 support Web servers run BSDI 2.0--an Intel-based Unix--rather than Windows NT, which Microsoft insists is the ideal Web software solution. Does Redmond know something we don't know?" -Robert X. Cringely, INFORWORLD, 9/11/95 From firewalls-owner Thu Dec 7 09:09:33 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA28317 for firewalls-outgoing; Thu, 7 Dec 1995 08:13:30 -0800 (PST) Received: from galby.ipp.pt (galby.ipp.pt [193.136.60.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA28312 for ; Thu, 7 Dec 1995 08:13:19 -0800 (PST) Received: by galby.ipp.pt (5.65/DEC-Ultrix/4.3) id AA21786; Thu, 7 Dec 1995 17:13:03 GMT Date: Thu, 7 Dec 1995 17:13:03 GMT Message-Id: <9512071713.AA21786@galby.ipp.pt> X-Sender: npll@galby.ipp.pt X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 (Highest) To: firewalls@GreatCircle.COM From: Nuno Leitao Subject: IP Filter for Linux. Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hello. I have tried to use Drawbridge (from Texas A&M University) as a packet filter for my network, but, I have just had headackes with it... Could some one please suggest me a good IP packet filter that would run on a PC with DOS or a PC with Linux ? Thank You. --Nuno Leitao (nleitao@ipp.pt) / _/_ o __/ / o _ _ <_(_/__<____<_/_)_/_)_ / / ' ' Network Operations Center, Instituto para o Desenvolvimento Tecnologico, Instituto Politecnico do Porto, Porto, Portugal. From firewalls-owner Thu Dec 7 09:31:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA24706 for firewalls-outgoing; Thu, 7 Dec 1995 06:28:36 -0800 (PST) Received: from solar.sky.net (solar.sky.net [198.70.175.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA24697 for ; Thu, 7 Dec 1995 06:28:31 -0800 (PST) Received: from skynet.sky.net (ip049.sky.net [205.242.50.49]) by solar.sky.net (8.6.12/8.6.12) with SMTP id IAA00761 for ; Thu, 7 Dec 1995 08:27:41 -0600 Date: Thu, 7 Dec 1995 08:27:41 -0600 Message-Id: <199512071427.IAA00761@solar.sky.net> X-Sender: gabriel@sky.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@GreatCircle.com From: gabriel Subject: Pop mail through firewall Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Please pardon this clutter. I'm sure this topic is well-known, but I haven't seen it on the list in my short tenure. Judging from some of the messages and authors I see in my mailbox this list has no shortage of expertise. I'm trying to allow clients on the protected side of the firewall access an unprotected mail host in our DMZ. I'm using Gauntlet 3.0 for Irix 5.3, with smapd proxy running. Someone has mentioned that I should look at plug_gw from TIS. Another alternative, I think, is to have an internal mail host, and configure sendmail on the unprotected mail host to forward to it. Any opinions on this? It occurs to me that this setup would by nature compromise the security, at least, of the mail messages themselves, although it may be more secure in general for our network. Any and all help appreciated in advance for this poor beginner. Please respond on this list if necessary, ideally via direct e-mail to gabriel@sky.net, to avoid cluttering this list further. Thanks --John McPhail (gabriel@sky.net) From firewalls-owner Thu Dec 7 09:49:48 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA27630 for firewalls-outgoing; Thu, 7 Dec 1995 07:58:16 -0800 (PST) Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id HAA27614 for ; Thu, 7 Dec 1995 07:58:10 -0800 (PST) Received: from faui45.informatik.uni-erlangen.de by relay4.UU.NET with SMTP id QQztch06226; Thu, 7 Dec 1995 10:56:36 -0500 (EST) Received: from faui01.informatik.uni-erlangen.de (root@faui01.informatik.uni-erlangen.de [131.188.2.1]) by uni-erlangen.de with ESMTP id QAA24124 (8.6.12/7.4f-FAU);; Thu, 7 Dec 1995 16:39:45 +0100 Received: from fritzchen (tnsturm@faui04f.informatik.uni-erlangen.de [131.188.63.15]) by cip.informatik.uni-erlangen.de with SMTP id QAA13574 (8.6.12/7.4f-FAU);; Thu, 7 Dec 1995 16:39:42 +0100 Message-ID: <30C70ABD.16D348B@cip.informatik.uni-erlangen.de> Date: Thu, 07 Dec 1995 16:39:41 +0100 From: Torsten Sturm Organization: CSD, Univ. Erlangen-Nuernberg X-Mailer: Mozilla 2.0b3 (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: Kenneth Smith CC: firewalls@greatcircle.com Subject: Re: NT Security and NTFS References: <9512062259.AA1684@worldcom-45.worldcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Kenneth Smith wrote: > I know that this question presupposes physical access to the machine in > question, and if that happens there are any number of possible back-doors, but > it still strikes me as a rather large loophole. Sure, it is no problem to install another new NT to the same partition and then have full access to all files. NT is only C2 certifyable, and C2 secure only together with C2 secure hardware, which then would prevent access to the hardware at some level. Only encryption would do the trick here, but this is the same to unixes or other operating systems. If you have physical access with no restrictions, then nothing without encryption is secure... Torsten -- InfoSec webpage : http://www.rrze.uni-erlangen.de/~unrzg3/security/security.html __________________________________________________________________ http://wwwcip.informatik.uni-erlangen.de/user/tnsturm/index.html From firewalls-owner Thu Dec 7 09:52:58 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA27947 for firewalls-outgoing; Thu, 7 Dec 1995 08:04:36 -0800 (PST) Received: from gauntlet-1.trusted.com (gauntlet-1.trusted.com [204.254.155.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA27942 for ; Thu, 7 Dec 1995 08:04:32 -0800 (PST) Received: by gauntlet-1.trusted.com; id LAA02629; Thu, 7 Dec 1995 11:09:58 -0500 Received: from hilo.trusted.com(10.0.1.126) by gauntlet-1.trusted.com via smap (T3.1) id xma002621; Thu, 7 Dec 95 11:09:57 -0500 Received: by hilo.trusted.com (1.37.109.4/16.2) id AA12180; Thu, 7 Dec 95 11:04:56 -0500 Date: Thu, 7 Dec 1995 11:04:52 -0500 (EST) From: David I Dalva To: Rick Smith Cc: Anton J Aylward , firewalls@GreatCircle.COM Subject: Re: chroot/setuid vs type enforcement In-Reply-To: <199512051645.KAA06388@shade.sctc.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > A high security application (i.e. one that is likely to be subjected > to serious attacks and needs strong integrity protection against these > attacks) needs help from the underlying OS to limit the attack's > potential damage. That's why the Orange Book put mandatory protection > into B and A level systems -- the protection tries to enforce the > security policy even in the face of misbehaving programs that try to > violate it. That's what we do with Type Enforcement on Sidewinder. I agree that type enforcement provides for a higher-assurance firewall, by implementing a mandatory access control policy in the kernel that all applications must abide by. In a firewall context, this means the proxies are bound by the MAC policy. What an application-gateway firewall does for you is control access between networks with different levels of trust via the proxies. It is therefore crucial that the proxies be correct, less so the added process access control facilities in the kernel. That's what we do with Small-and-Simple-Proxies/Source-Code-Availability/ Least-Privilege on Gauntlet. Dave Dalva Trusted Information Systems, Inc. +1.301.527-9500 x105 2277 Research Boulevard +1.301.527-0482 FAX Rockville, MD 20850 From firewalls-owner Thu Dec 7 09:54:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA02405 for firewalls-outgoing; Thu, 7 Dec 1995 09:35:06 -0800 (PST) Received: from bwh.harvard.edu (bwh.harvard.edu [134.174.81.34]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA02381 for ; Thu, 7 Dec 1995 09:34:58 -0800 (PST) Received: from cushing.bwh.harvard.edu (cushing.bwh.harvard.edu [134.174.81.60]) by bwh.harvard.edu (8.6.9/8.6.9) with ESMTP id MAA06326; Thu, 7 Dec 1995 12:35:56 -0500 From: Adam Shostack X-Organization: Brigham & Womens Hospital, A Teaching Affiliate of Harvard Medical School Received: by cushing.bwh.harvard.edu (8.6.9) id MAA02850; Thu, 7 Dec 1995 12:22:20 -0500 Message-Id: <199512071722.MAA02850@cushing.bwh.harvard.edu> Subject: Re: Mathematical Proof of RSA Encryption To: jpilley@lioninc.com (John Pilley) Date: Thu, 7 Dec 1995 12:22:18 -0500 (EST) Cc: firewalls@GreatCircle.COM In-Reply-To: <9512062150.aa07393@dvlp1.lioninc.com> from "John Pilley" at Dec 6, 95 09:49:29 pm X-PGP: 0xE794DA91 FD3C3450FEB4A0B8 18F2E72CA82D29B8 X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk John Pilley wrote: | The asynchronous scheme of encryption/decryption invented by Rivest, Shamir | & Adleman involves the use of multiplicative inverses, a modulus and a | public and secret key chosen/derived from the primes whose product makes up | the modulus. | | Would one of you good people point me towards a proof(?), derivation(?), | explanation(?) showing (Mathematically) how it works? A very good introduction to cryptography is Bruce Schneier's 'Applied Cryptography' now in a second edition. It takes you through all the math you need to understand RSA, as well as many other cryptosystems. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume From firewalls-owner Thu Dec 7 10:11:34 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA24178 for firewalls-outgoing; Thu, 7 Dec 1995 06:05:59 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA24173 for ; Thu, 7 Dec 1995 06:05:53 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id JAA24196; Thu, 7 Dec 1995 09:06:15 -0500 Date: Thu, 7 Dec 1995 09:06:15 -0500 Message-Id: <199512071406.JAA24196@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Chris Liljenstolpe (Swanson) - SSDS" From: Anton J Aylward Subject: Re: Firewalls for the rest of us (was Re: A1 Systems) Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 22:06 5/12/95 -0600, Chris Liljenstolpe wrote: >Greetings, > > Actually, I see this system being adequately reflected in a >two-dimensional graph. The Y-axis is cost and the X-axis is level of >security. One curve is the level of security vs. the cost of that security >(this includes actual costs, difficulty of use/unavailability of >resources/information, etc.). The second curve is the cost of exposure vs. >level of security. This curve measures the potential cost to an >organization if an exposure is exploited (and amortizes it for probability >of exploitation). Both of these curves are asymptotic. Where they cross is >the minimum point, and therefore where total costs are at the minimum. > > Regards, > -=Chris Thank you Chris, you put it so much better. I guess I've become to dependant on the visual aids in my presentations, I show the graph rather than describe it. >(>Anton J Aylward writes about trading cost of loss >(>against cost of security: >(> >(>> Visualize a graph if you will, two curves: A/x and B-(C/x) One curve >(>> is the value of what you want to protect, the other is what you are >(>> spending on protecting. You're plotting cost of security vs exposure. >(>> Somewhere the curves cross, your cost of righ and your cost of >(>> protection are in balance. >(> > --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Thu Dec 7 10:24:26 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA04053 for firewalls-outgoing; Thu, 7 Dec 1995 09:59:57 -0800 (PST) Received: from tera.bctel.net (tera.bctel.net [204.174.66.253]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id JAA04048 for ; Thu, 7 Dec 1995 09:59:52 -0800 (PST) Received: (from nobody@localhost) by tera.bctel.net (8.7.1/8.7.1) id KAA22088; Thu, 7 Dec 1995 10:00:36 -0800 (PST) X-Authentication-Warning: tera.bctel.net: nobody set sender to using -f Received: from mocha.bctel.net(204.174.66.5) by tera via smap (V1.3) id sma022086; Thu Dec 7 10:00:29 1995 Received: (from murrell@localhost) by mocha.bctel.net (8.7.1/8.7.1) id KAA02808; Thu, 7 Dec 1995 10:00:43 -0800 (PST) Date: Thu, 7 Dec 1995 10:00:43 -0800 (PST) From: Brian Murrell Message-Id: <199512071800.KAA02808@mocha.bctel.net> To: firewalls@GreatCircle.COM, jpilley@lioninc.com Subject: Re: Mathematical Proof of RSA Encryption Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: Y6Ks9T/dDJ3fmbtjTmVDjA== Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > The asynchronous scheme of encryption/decryption invented by Rivest, Shamir > & Adleman involves the use of multiplicative inverses, a modulus and a > public and secret key chosen/derived from the primes whose product makes up > the modulus. > > Would one of you good people point me towards a proof(?), derivation(?), > explanation(?) showing (Mathematically) how it works? Whoa!! This is really eerie. I just finished reading all about how and why it works. I can't say I understood it all on the first pass, I'm sure I'll be reading it again. Basically the "security" of RSA is dependent on the inability to factor big numbers. I found the text I read very comprehensive. Try picking up "NETWORK SECURITY PRIVATE Communication in a PUBLIC World" by Charlie Kaufman, Radia Perlman, and Mike Speciner (ISBN 0-13-061466-1). b. -- Brian J. Murrell murrell@bctel.net BCTel Advanced Communications brian@ilinx.com Vancouver, B.C. brian@wimsey.com 604 454 5261 From firewalls-owner Thu Dec 7 10:54:26 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA04376 for firewalls-outgoing; Thu, 7 Dec 1995 10:04:36 -0800 (PST) Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.6]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA04364 for ; Thu, 7 Dec 1995 10:04:31 -0800 (PST) Received: from smtpgty.saicuk.co.uk by flow.pipex.net with SMTP (PP); Thu, 7 Dec 1995 17:45:29 +0000 Received: by smtpgty.saicuk.co.uk with Microsoft Mail id <30C726CB@smtpgty.saicuk.co.uk>; Thu, 07 Dec 95 17:39:23 GMT From: "Johnson-Bryden, Ian" To: "'firewalls@greatcircle.com'" Subject: RE: Outbound Authentication Date: Thu, 07 Dec 95 17:04:00 GMT Message-ID: <30C726CB@smtpgty.saicuk.co.uk> X-Mailer: Microsoft Mail V3.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Posting was: From: firewalls-owner To: firewalls Subject: Outbound Authentication Date: Thursday, December 07, 1995 5:30AM Hi, My company's net security is relatively weak, and we are currently going through Firewalling & all of that good stuff. We have a large dialup community that needs access to our internal network, and to the Internet. We are handling this with the multi-homed configuration. The issue is the following. We as security think we should have users authenticate while dialing up to get to either the internal net or the \ Internet. The primary rationale is that the logging on the remote access server product is weak, and that static passwords are weak. It also concedes that every environment has "insider risk", and we need some way of knowing who is doing what....even if they are just going out to the Internet. Any thoughts / comments? Anyone gone through this debate? Thanks in advance. ************************************************ Comment is: Probably most readers/posters/lurkers have been through this debate at some stage and there is no standard answer. It all comes down to trade offs and perceived values. You could give every user a portable identity and a security profile. That way any workstation can be used by any authorised user. Your internal network could be set up as a multi-level secure environment and each authorised user would see only what the personal profile allowed. You would have a trusted audit of every transaction and you could have automated support tools which would produce any form of analysis which you might desire. You could even go further and have the system set up so that when an employee was due to be fired, the system sucked everything off his pc/workstation next time he logged in and froze his machine so that only the company security officer could make it work again. The other end of the scale is that you sit there and do nothing. Your approach will be somewhere between those two points. The key questions will be:- a) Have you move far enough along the line to adequately contain risk for your enterprise (that assumes that you have identified the risks, ranked them, and decided which have to be reduced how far) or b) Have you gone further than you need and spent too much money Some might also say that if you go too far towards high level effective security you reduce availability. OTOH if you design the system correctly you can safely provide improved access and very high integrity. Ian J-B From firewalls-owner Thu Dec 7 11:01:32 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA25013 for firewalls-outgoing; Thu, 7 Dec 1995 06:35:49 -0800 (PST) Received: from Disclosure.COM (di2.disclosure.com [205.156.194.11]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA25004 for ; Thu, 7 Dec 1995 06:35:40 -0800 (PST) Received: by Disclosure.COM (4.1/SMI-4.1) id AA29761; Thu, 7 Dec 95 09:39:25 EST Date: Thu, 7 Dec 1995 09:39:24 -0500 (EST) From: Scott Barman To: "Marcus J. Ranum" Cc: Mike Shaver , mjr@iwi.com, firewalls@GreatCircle.COM Subject: Re: selection criteria? In-Reply-To: <199512070329.WAA05922@switchblade.iwi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Wed, 6 Dec 1995, Marcus J. Ranum wrote: > Mike Shaver writes: > >I'm beginning to feel a little lonely, but am I _really_ the only one > >who sees security as a feature? > > I do!!! Security is a feature (almost a side-effect) of a well > designed system. But one of the important things about security is that > you have to be able to make MONEY off it. And be able to parlay it into good P.R. > Vendors, at least in the UNIX space, would rather spend their > R&D $$ making cool new chips, better graphics, faster disks, and > cheaper boxes, than security. Because they lose money on security > and they make money on faster disks, etc. This is yet another of > the ways in which I believe the orange book has set back computer > security's evolution: by making security a severe *expense* in the > development cycle, it has done more than any other single thing to > convince the vendors that security is something to stay the hell > away from. While the orange book is a guide, I do not believe the vendors are even considering it in their design. Recently, I have been in discussion with a few vendors on their attitude twoard security and their response is "this is not what the users want. We have marketing surveys...." Me, being a curious person, I ask who is being included in the surveys, the CIO's, high level managers, those who haven't seen a line of code in 10 years, or those of us in the trenches who have typer's cramps from chasing down the problems vendors leave for us? That's when the conversation stops? That question is usually a conversation ender. I call it the "Gee whiz" Syndrome. All these vendors want something in their ads that will make these people go "gee whiz, that's neat" rather than something that would actually work for the user. It seems the only time most Unix vendors show an interest in security is when someone issues a security alert about their system. In other words they're reactive rather than proactive. > In order to reverse the trend, we (the amalgamated union > of security dweebs local #1024) need to position security as an I like that name! :-) > enabling technology. It's hard. It means telling people, "Hey! > That cool thing you want to do? You couldn't do that unless the > system supported these basic security services" or whatever. The I was told when security hits the top 10 of desired features, then the vendors will pay attention to it. Not before. It took how long for automakers to stop offering shoulder straps as an option? > brightest raw of sunshine I've seen for a while is Sun's success > positioning Java as a bitchin' cool thing and that SECURITY is > part of the bitchin' coolness of it. The fact that they accomplished > a market sell on that fact is good news; it means that people are > learning to ask for systems that are more than spit and glue and > duct tape. Sure... Sun did that AFTER its potential security problems were beaten up here and on other mailing lists and newsgroups. Yes, I know they put out their white paper on their security position. But Sun did not start to advertise it with its security "feature" until AFTER the onslaught from the union. Again, they were reactive rather than proactive. To my knowledge only DEC and IBM have proactive groups (among Unix vendors) solely concerned with security. Yes, I know DEC was first (SEAL), but IBM has always been proactive with computing security (on their mainframes) and now has extended that to their Unix offerings. scott barman -- scott barman DISCLAIMER: I speak to anyone who will listen, scott@disclosure.com and I speak only for myself. barman@ix.netcom.com "I don't know if security explains why the Win95 support Web servers run BSDI 2.0--an Intel-based Unix--rather than Windows NT, which Microsoft insists is the ideal Web software solution. Does Redmond know something we don't know?" -Robert X. Cringely, INFORWORLD, 9/11/95 From firewalls-owner Thu Dec 7 11:06:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA23683 for firewalls-outgoing; Thu, 7 Dec 1995 05:59:17 -0800 (PST) Received: from mail.state.mn.us (fax.state.mn.us [204.73.26.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id FAA23678 for ; Thu, 7 Dec 1995 05:59:13 -0800 (PST) Received: from notes.mdor.state.mn.us by mail.state.mn.us; Thu, 7 Dec 95 08:00:13 -0600 Received: by notes.mdor.state.mn.us (IBM OS/2 SENDMAIL VERSION 1.3.2)/1.0) id AA-326; Thu, 07 Dec 95 07:58:23 -0800 Message-Id: <9512071558.AA-326@notes.mdor.state.mn.us> Received: from RISD with "Lotus Notes Mail Gateway for SMTP" id E8D206BF8C0958AE8625628B004C3022; Thu, 7 Dec 95 07:58:22 To: firewalls From: Eric Pederson Date: 7 Dec 95 7:59:33 EDT Subject: Re: Poking a hole in the firewall Mime-Version: 1.0 Content-Type: Text/Plain Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > I have a Web server. This web server needs to get some data off > of another machine, inside my firewall. My programmer wants to write > his own little home grown TCP/IP application to communicate between > his program on my web server and his program on my interal machine. > He tests it internally, and it works fine. He puts his application on the > web server and I poke a hole in the router and the application does > not work. This sounds a lot like he's using the portmapper. There are better ways, like using inetd or having the program listen on a static port. -- Eric L. Pederson Work: eric_pederson@notes.mdor.state.mn.us System Architect Home: eric@winternet.com MN Department of Revenue (612) 215-0499 --- These opinions aren't even mine, much less MDOR's --- From firewalls-owner Thu Dec 7 11:14:10 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA27104 for firewalls-outgoing; Thu, 7 Dec 1995 07:41:18 -0800 (PST) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id HAA27088 for ; Thu, 7 Dec 1995 07:41:10 -0800 (PST) Received: from uucp6.UU.NET by relay5.UU.NET with SMTP id QQztcg03159; Thu, 7 Dec 1995 10:42:09 -0500 (EST) Received: from smw002.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Thu, 7 Dec 1995 10:42:10 -0500 Received: from wks25006.ibx.com by ibx.com (4.1/SMIbc-4.1) id AA29211; Thu, 7 Dec 95 10:22:49 EST Date: Thu, 7 Dec 95 10:22:49 EST From: c62fi89@ibx.com (Robert Turner) Message-Id: <9512071522.AA29211@ibx.com> To: Firewalls@GreatCircle.COM Subject: Re: Firewalls-Digest V4 #695 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk No one needs to write a driver to do this. Just reinstall NT over top of existing NT install. Any NTFS partitions will then be accessable by the newly created administrator account. Initially the admin may not have access, but he/she will have the power to grant himself access. The only way to secure any disk volume is with encription. Server needs to be in a secure area otherwise it is not secure. Bob [From: Kenneth Smith [Date: 6 Dec 95 15:50:06 [Subject: NT Security and NTFS [ [Questions about NT security have been tossed around quite a bit lately, but I [have a new one to add to the pot. [ [One of the claims which NT makes to security is its NTFS file system, which [unlike FAT supports permissions natively. It is, for instance, a required [element of NT's C2 configuration. [ [But as I understand it . . . wouldn't it be possible to write or obtain an NTFS [file system driver for some alternate OS which supports installable file [systems (i.e., Windows 95, Linux)? If this is the case, wouldn't this mean [that booting to or installing that OS on anotherwise supposedly secure system [would grant the user unrestricted access to the file system? I would imagine [that some enterprising individual could even come up with a way to boot the [file system and a simple command-line interface off of a floppy. [ [I know that this question presupposes physical access to the machine in [question, and if that happens there are any number of possible back-doors, but [it still strikes me as a rather large loophole. [ [Comments? [ [Ken Smith [Independent National Mortgage [ From firewalls-owner Thu Dec 7 11:24:12 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA27875 for firewalls-outgoing; Thu, 7 Dec 1995 08:03:25 -0800 (PST) Received: from safety.worldcom.com (safety.worldcom.com [198.64.193.5]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id IAA27863 for ; Thu, 7 Dec 1995 08:03:18 -0800 (PST) Received: (from smtp@localhost) by safety.worldcom.com (8.7.1/8.6.9) id JAA12764 for ; Thu, 7 Dec 1995 09:32:25 -0600 (CST) Received: from worldcom-45.worldcom.com(198.64.193.76) by safety.worldcom.com via smap (V1.3) id sma012642; Thu Dec 7 09:31:07 1995 Received: by worldcom-45.worldcom.com (IBM OS/2 SENDMAIL VERSION 1.3.14/3.3) id AA5632; Thu, 07 Dec 95 09:31:46 -0500 Message-Id: <9512071431.AA5632@worldcom-45.worldcom.com> Received: from worldcom with "Lotus Notes Mail Gateway for SMTP" id E157A194597A82288625628B005517ED; Thu, 7 Dec 95 09:31:46 To: firewalls From: Kenneth Smith Date: 7 Dec 95 7:19:59 Subject: Re: TokenRing Firewalls Mime-Version: 1.0 Content-Type: Text/Plain Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Darren Reed wrote: >> I have recently joined this group in hopes of seeing how to protect our >> network(s). In all the conversations I have been following, I have only >> seen refernces to Ethernet. I am wondering if there are any TokenRing >> based firewall packages? We are mostly TR with some Ethernet. We do have >> a couple of Cisco routers (2500 & 4000's). We are TR attached to our service >> provider thru the 2500. Any comments would be appreciated. >The link layer (Token Ring/Ethernet/PPP) should not make any difference to >your firewall. If you go for the proxy firewall, it makes 0 difference, >only some packet filter types might have trouble if they've only been >implemented to support Ethernet frames. ie it won't be of concern to your >ciscos if you include them as part of your firewall. >The only box that I could imagine having some trouble would be SunScreen >(or other NATs) which don't plug into Token Ring (?). In theory this should be so -- Token Ring and Ethernet are both packet-based media whose packets can be made to correspond on a roughly 1:1 basis with IP datagrams. This makes it much easier to support at the network level than, say, ATM cells. Unfortunately, the realities of the marketplace dictate that it is not always true. Firewalls based on proprietary OS's or extremely stripped-down unix variants typically provide driver support for only a limited number of network cards -- and token-ring cards generally aren't high on their list. For instance, the Borderware firewall which our company has purchased supports only Ethernet -- while our shop is straight Token-Ring. So add another $4000 or so (and added complexity and hop-counts) for a router to sit between our main network and the Ethernet hub to which our firewall is connected. It's not that they can't, or even that it would be particularly difficult. They just haven't gotten around to it. Ken Smith Independent National Mortgage From firewalls-owner Thu Dec 7 11:35:52 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA03944 for firewalls-outgoing; Thu, 7 Dec 1995 09:58:38 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA03922 for ; Thu, 7 Dec 1995 09:58:29 -0800 (PST) Received: from splinter.rtp.dg.com by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA21507; Thu, 7 Dec 1995 12:59:25 -0500 Received: by splinter (8.6.10/rtp-s04) id RAA17393; Thu, 7 Dec 1995 17:58:17 GMT From: spencerj@dg-rtp.dg.com (Jon Spencer) Message-Id: <199512071758.RAA17393@splinter> Subject: NT Security and NTFS (fwd) To: firewalls@greatcircle.com Date: Thu, 7 Dec 95 12:58:14 EST X-Mailer: ELM [version 2.3 PL11] Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > Questions about NT security have been tossed around quite a bit lately, but I > have a new one to add to the pot. > > One of the claims which NT makes to security is its NTFS file system, which > unlike FAT supports permissions natively. It is, for instance, a required > element of NT's C2 configuration. > > But as I understand it . . . wouldn't it be possible to write or obtain an NTFS > file system driver for some alternate OS which supports installable file > systems (i.e., Windows 95, Linux)? If this is the case, wouldn't this mean > that booting to or installing that OS on anotherwise supposedly secure system > would grant the user unrestricted access to the file system? I would imagine > that some enterprising individual could even come up with a way to boot the > file system and a simple command-line interface off of a floppy. > > I know that this question presupposes physical access to the machine in > question, and if that happens there are any number of possible back-doors, but > it still strikes me as a rather large loophole. > > Comments? > > Ken Smith > Independent National Mortgage > Regardless of the system, if you have physical access to the box, you have very few options. Without commenting on the relatively poor protection that C2 and DAC give you, let me detail the options I see. 1) If you can boot an arbitrary device (e.g., tape, floppy), you can get direct access to the disk via any software you can come up with. 2) To get around this, you can have a password protected boot ROM. 3) To get around the password protected boot ROM, you can: a. replace the boot ROM b. remove the disk drive 4) to protect against (3), you can make the box impenetrable (e.g., put an explosive charge in the box that goes of if you touch the box :-). OR - you can logically protect the information (which is necessary if you want to protect info on things like notebooks). That is the approach we are taking. The data can be protected with encryption and digital signature such that you can highly control access. For example, you can set it up so that the information can only be accessed when running a specific program, or only when attached to a specific server, or only if you have some special knowledge (i.e., a hand held device, an encryption key, etc.) The last approach is obviously theone that I favor, but the others can be used. -- Jon F. Spencer spencerj@rtp.dg.com (uunet!rtp.dg.com!spencerj) Data General Corp. Phone : (919)248-6246 62 T.W. Alexander Dr, MS #119 FAX : (919)248-6108 Research Triangle Park, NC 27709 Office RTP 121/9 Reality is an illusion - perception is what counts. No success can compensate for failure at home. President David O. McKay ***** UCC 1-207 ******** From firewalls-owner Thu Dec 7 11:49:32 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA26510 for firewalls-outgoing; Thu, 7 Dec 1995 07:23:54 -0800 (PST) Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.6]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA26500 for ; Thu, 7 Dec 1995 07:23:50 -0800 (PST) Received: from london.ecaltd.com (actually london.ecaltd.co.uk) by flow.pipex.net with SMTP (PP); Thu, 7 Dec 1995 15:24:21 +0000 Received: by london.ecaltd.com with Microsoft Mail id <30C7072D@london.ecaltd.com>; Thu, 07 Dec 95 15:24:29 GMT From: "Anthony.W.Youngman" To: "'_firewalls'" Subject: William of Occam Date: Thu, 07 Dec 95 15:21:00 GMT Message-ID: <30C7072D@london.ecaltd.com> X-Mailer: Microsoft Mail V3.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk William of Occam (or Ockham, in Yorkshire, or Surrey) was a medieval philosopher - presumed dates 1285-1349 - who is attributed with saying "Occam's razor", "Entia non sunt multiplicanda praeter necessitatem", or "Entities are not to be multiplied beyond necessity". The modern English version I am familiar with is: Make things as simple as possible - but no simpler. FWIW, Occam is now a programming language for MPP machines. It was designed for the transputer, an English processor chip that - seriously - should have bankrupted Intel. Unfortunately A Scotsman invented the telephone and the yanks made money We invented ASDIC and the yanks sold everyone SONAR We invented the microwave and the japs put them in every kitchen We invented the transputer and ended up giving it to the frogs who made a worse mess than we did :-) It all comes from accountants who will spend pounds to save pennies... From firewalls-owner Thu Dec 7 11:59:51 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA27077 for firewalls-outgoing; Thu, 7 Dec 1995 07:41:07 -0800 (PST) Received: from nic.abii.com (nic.abii.com [204.77.143.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA27070 for ; Thu, 7 Dec 1995 07:41:01 -0800 (PST) Received: (from mail@localhost) by nic.abii.com (8.6.12/8.6.11) id JAA18072 for ; Thu, 7 Dec 1995 09:42:04 -0600 Received: from mailserv.abii.com(204.77.144.103) by nic.abii.com via smap (V1.3) id sma018068; Thu Dec 7 09:41:53 1995 Received: by mailserv.abii.com with Microsoft Mail id <30C72685@mailserv.abii.com>; Thu, 07 Dec 95 09:38:13 PST From: Garry Garrett To: "'firewalls list from GreatCircle'" Cc: Simon Xiong Subject: Re: Poking a hole in the firewall Date: Thu, 07 Dec 95 09:36:00 PST Message-ID: <30C72685@mailserv.abii.com> X-Mailer: Microsoft Mail V3.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Thanks for all the responses. Here is a summary of what I have learned. I guess my #1 question was, can the application be written to only use one port, as opposed to using 1 port to open the connection, which then uses a random free port (like FTP). Many people have answered yes. This really means that I do only have to open up (proxy/filter...) one port. I guess this is really the part that is on topic, but to make this work you really need to know the answer to my 2nd question. My #2 question was, how does one write it to use only one port. I have gotten some good suggestions. Many have suggested the book, "Unix Network Programming" by W. Richard Stevens, ISBN 0-13-949876-1 as a reference. Others have given me a few starters. The most concise one being from Brent Chapman: > on the client side: > > use socket() to create a socket > use bind() to establish the address & port for your end > Typically you specify "0" for the port, which means > "next available". > use connect() to establish the connection to the other end > > On the server side, you: > > use socket() to create a socket > use bind() to establish the address & port for your end > You specify a particular port number for the server to use > use listen() to listen for incoming connections to that port. > When you get a connection, use accept() to accept the connection. > > If you want to run multiple single-threaded servers (a bunch of parallel > server processes, each talking to one client), you just do a fork() before > you do the accept(); have the child process handle the incoming connection, > and have the parent process loop back to doing a listen() for the next > connection. This is the way servers like sendmail work. > > If you want to run a multi-threaded server (a single server process talking > to multiple client processes), you just have to make sure it knows when to > listen() and how to accept() and juggle multiple simultaneous connections; > you'll probably have to learn to use select(). Lastly, someone had a very good suggestion about making sure that my programmer's server does some kind of authentication to make sure that it is talking the the program on my web server that my programmer wrote. I suppose that they meant something on the order of SKEY, but even a little bit of handshaking would be better than nothing. Perhaps the server sends some string and the client must send the correct response to the string that it was sent or else the server drops the connection. Garry Garry.Garrett@abii.com From firewalls-owner Thu Dec 7 12:17:26 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA06101 for firewalls-outgoing; Thu, 7 Dec 1995 10:36:36 -0800 (PST) Received: from relay.ashton.csc.com (relay.ashton.csc.com [20.2.54.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA06087 for ; Thu, 7 Dec 1995 10:36:29 -0800 (PST) Received: by relay.ashton.csc.com; id NAA03747; Thu, 7 Dec 1995 13:37:52 -0500 Received: from mccoy.ashton.csc.com(20.2.51.2) by relay.ashton.csc.com via smap (g3.0.1) id sma003743; Thu, 7 Dec 95 13:37:44 -0500 Received: (from ckostick@localhost) by mccoy.ashton.csc.com (8.6.9/8.6.9) id NAA05609; Thu, 7 Dec 1995 13:44:43 -0500 From: Chris Kostick Message-Id: <199512071844.NAA05609@mccoy.ashton.csc.com> Subject: Re: IP Filter for Linux. To: nleitao@ipp.pt (Nuno Leitao) Date: Thu, 7 Dec 1995 13:44:43 -0500 (EST) Cc: firewalls@greatcircle.com In-Reply-To: <9512071713.AA21786@galby.ipp.pt> from "Nuno Leitao" at Dec 7, 95 05:13:03 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > I have tried to use Drawbridge (from Texas A&M University) as a packet > filter for my network, but, I have just had headackes with it... > > Could some one please suggest me a good IP packet filter that would run on > a PC with DOS or a PC with Linux ? Linux has 'firewalling' (i.e. packet filtering) code within the kernel. You need to include it as a configuration option when building a new kernel. Is it good? I would say adequate. There are some deficiencies and commercial products are obviously much better, but it can (and does) fit into many (usually small) environments that only need packet filtering capabilities. -- chris From firewalls-owner Thu Dec 7 12:40:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA27301 for firewalls-outgoing; Thu, 7 Dec 1995 07:45:57 -0800 (PST) Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.6]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA27296 for ; Thu, 7 Dec 1995 07:45:51 -0800 (PST) Received: from smtpgty.saicuk.co.uk by flow.pipex.net with SMTP (PP); Thu, 7 Dec 1995 15:45:53 +0000 Received: by smtpgty.saicuk.co.uk with Microsoft Mail id <30C70AAE@smtpgty.saicuk.co.uk>; Thu, 07 Dec 95 15:39:26 GMT From: "Johnson-Bryden, Ian" To: "'firewalls@greatcircle.com'" Subject: Re: selection criteria? Date: Thu, 07 Dec 95 14:05:00 GMT Message-ID: <30C70AAE@smtpgty.saicuk.co.uk> X-Mailer: Microsoft Mail V3.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >mjr wrote: > Vendors, at least in the UNIX space, would rather spend their >R&D $$ making cool new chips, better graphics, faster disks, and >cheaper boxes, than security. Because they lose money on security >and they make money on faster disks, etc. This is yet another of >the ways in which I believe the orange book has set back computer >security's evolution: by making security a severe *expense* in the >development cycle, it has done more than any other single thing to >convince the vendors that security is something to stay the hell >away from. I *would agree* that most vendors dont worry about risk in their products, just sexy things they can market simply. Thats not confined to computers. People use recycled components from crash sites in the 747 you fly in, vehicle manufacturers produce products which are easy to steal and dangerous to drive, theatre owners still padlock fire exits, etc. It a pretty rotten world out there, but thats only because most customers are too lazy to look to their own interests and buy inferior products because they are cheap or sold with clever marketing. I *dont agree* that Orange Book as a criteria necessarily made products expensive. When it was introduced all those years ago, the computing world was very different from what it is today. Unfortunately the Rainbow Series never kept up and the US Government was on occassion highly uncooperative with other nations who saw the defects and had solutions. ITSEC grew out of that European frustration and it was a major advance, retarded by mistaken attempts to smooth ruffled US feathers. iCC may prove to be a horrible compromise reflecting nationalist attitudes - I hope not, but it is a very real risk. That said its not the criteria which makes the certified products cost more, but a cocktail of factors including:- The method of operation of the criteria is a factor and Orange Book required product evaluated in the national interest and treated anything worthwhile as some sort of US state secret to be shared only amongst close friends. That made the market very small and even Windoze would cost mega bucks if Brother Bill had to rely on someone deciding who he could sell to and limiting sales to a few copies a year. Evaluation process is another factor and Orange Book is typically 15% of the speed of ITSEC even though it requires less from the vendor. OTOH, TCSEC evaluations are not charged at commercial rates to the vendor but are a public service in the vested US national interest. Vendor approach is very important and a number of vendors have certainly taken the view that US Govt will have to pay for the sort of Federal Sales Teams which the bureaucracy requires. That is not so much Orange Book related but simple commercial approaches. It has never failed to amaze me how much government spends on setting procurement systems to get best value and lowest prices and then goes out and buys $800 toilet seats for airbase washrooms. Not every reader of this post may understand some US Govt contracting requirements, but one favoured requirement is that the vendor sign his life away that no other customer shall receive said product at a lower price than USG pays. Of course the vendors may not be heartbroken about USG insisting that they overcharge *every* customer, but it does stop a product becoming a commodity. It also means that the non-govt. customer is buying a sales operation designed to support a bureaucracy he doesnt have and doesnt want. At risk of encouraging a flamethrower contest, some of those vendors who are starting to hype their certified products are very keen to sell at very high prices for as long as possible and prove that selling trusted products can be *very* profitable. What they have found from research is that most customers are starting to wonder about some of their accepted buying decisions and realising that putting a faulty workstation on every desk and connecting it and the outside world to every information asset may not be the way to go. Thats just the market becoming more mature and the customers better informed. One risk with certified products is that it becomes a number war where the vendors outbid eachother working up the alphabet soup list and turn certificate numbers into easy to digest selling features. I may not always agree with everything mjr posts, but he does think his way through which can be a reason for any vendor trying to plant a new marcom message trying to rubbish him. Its always painful if you worked out a wonderful marketing message about the emperor's new clothes and some ragged kid points out that they dont exist. Of course the ragged kid might be wrong ( not mjr that I would suggest that you are either ragged, or a kid, and right and wrong are perceptions to be argued in each case) but he has applied experience, observation and logic and not just followed the rest of the sheep. One motivation behind ITSEC was to force prices down through greater market and competition and some US vendors really did not like that approach one little bit. However, the one item which usually makes a certified product more costly is that it has to do what the documentation says rather than what the salesman claims. Having been involved in evaluations under several different criteria, and now preparing for an early trial iCC evaluation, I am fairly familiar with the re-engineering requirements for converting an untrustworthy commercial product into a trusted product. In some cases it would be much easier to drop the popular commercial product down the toilet where it would be comfortable and start again with a clean sheet. Unfortunately, customers really like their popular products and some find the little glitches homely, like unforecast crashes, memory wipes, frozen screens and all the other features which have made popular products so well loved. Not only is it fun, but the product didnt cost much and the salesman told us they would fix the problem in the next release - well maybe, or at least in the release after that, but did you know there was a new hypadrive version coming out next quarter so you need to change to the new product anyway. I dont claim trusted products are glitch free but they are low glitch and they are much more accurately documented and someone else has tried pulling the product apart and proving that it does what it claims. that costs money because it adds time. Any coder knows the difference between hacking out a bit of code that probably works, and doing the job so that others can use it and understand it and have it work reliably. Of course it all gets interesting when someone like Microsoft sees the light and takes Windows NT for an earth shattering Orange Book C2 and then starts to market this 'highly secure' product. That puts it on a par with virtually all flavours of standard UNIX. Wonder how long before they bite the bullet and try walking it through ITSEC/iCC for an earth shattering E2 ticket. I would be interested to see if it could make it. Most US C2 products end up requiring some major enhancements to pass the theoretically equivalent ITSEC grade. Ian J-B From firewalls-owner Thu Dec 7 12:44:53 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA01398 for firewalls-outgoing; Thu, 7 Dec 1995 09:17:30 -0800 (PST) Received: from server1.ols.net (server1.ols.net [206.27.1.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA01393 for ; Thu, 7 Dec 1995 09:17:25 -0800 (PST) Received: from mspeas.ols.net (mspeas.ols.net [205.139.152.179]) by server1.ols.net (8.6.12/8.6.9) with SMTP id MAA20827; Thu, 7 Dec 1995 12:10:04 -0500 Date: Thu, 7 Dec 1995 12:10:04 -0500 Message-Id: <199512071710.MAA20827@server1.ols.net> X-Sender: mspeas@rmic.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Kenneth_Smith@countrywide.com, firewalls-digest@GreatCircle.COM From: Mike Speas Subject: RE: NT Security and NTFS Sender: firewalls-owner@GreatCircle.COM Precedence: bulk That is also assuming that the server is configured to boot first from floppy, which in conjunction with physical access pretty much messes up your securty. NT can't control everything but they do include a good tool in thier Resource Kit for accessing possible security holes. But remember the most important security is physical security! Mike Speas Republic Mortgage Insurance Company ---------------------------------------------------------------------------- ---------------- Subject: NT Security and NTFS Author: Kenneth Smith at ccSMTP Date: 12/6/95 3:50 PM Questions about NT security have been tossed around quite a bit lately, but I have a new one to add to the pot. One of the claims which NT makes to security is its NTFS file system, which unlike FAT supports permissions natively. It is, for instance, a required element of NT's C2 configuration. But as I understand it . . . wouldn't it be possible to write or obtain an NTFS file system driver for some alternate OS which supports installable file systems (i.e., Windows 95, Linux)? If this is the case, wouldn't this mean that booting to or installing that OS on anotherwise supposedly secure system would grant the user unrestricted access to the file system? I would imagine that some enterprising individual could even come up with a way to boot the file system and a simple command-line interface off of a floppy. I know that this question presupposes physical access to the machine in question, and if that happens there are any number of possible back-doors, but it still strikes me as a rather large loophole. Comments? Ken Smith Independent National Mortgage From firewalls-owner Thu Dec 7 12:58:00 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA03705 for firewalls-outgoing; Thu, 7 Dec 1995 09:54:08 -0800 (PST) Received: from mail1.is.net (mail1.is.net [198.69.24.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA03679 for ; Thu, 7 Dec 1995 09:53:59 -0800 (PST) Received: from mrdata.is.net (mrdata.is.net [198.69.24.6]) by mail1.is.net (8.6.11/8.6.12) with SMTP id MAA18571 for ; Thu, 7 Dec 1995 12:55:21 -0500 Date: Thu, 7 Dec 1995 13:51:52 -0500 (EST) From: Alex Filacchione To: firewalls@greatcircle.com Subject: ftp & PASV Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Fri, 1 Dec 1995, Sten Drescher wrote: > Well, the SOCKS ftp client uses (I think) the PASV command to > tell the ftp server to use passive TCP ports for transfers. That is, > rather than the ftp server creating the connection to the client, it > opens a port, tells the client what port to connect to, and waits for > the client to create the connection. This way, the connection is > originating inside the SOCKS firewall, instead of outside it. > There are ftp clients/servers who do not understand the PASV command. Anyone know how prevalent these are, and if this is something to be worried about? IOW, should I set up an ftp that issues the PASV command, or should I use something like relay and have it sent to other ports, and what problems would this cause? Obviously the incoming ftp call would have to come to the gateway or firewall running relay. What are the configuration issues w/ this? Thanks, Brain21 FailureReason: MailEx0105: Unable to deliver message to cc:Mail. IntendedRecipient: firewalls@GreatCircle.COM at UNIXGATE@ccMail From firewalls-owner Thu Dec 7 12:58:29 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA26706 for firewalls-outgoing; Thu, 7 Dec 1995 07:29:18 -0800 (PST) Received: from neon.ingenia.com (neon.ingenia.com [205.207.219.29]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA26699 for ; Thu, 7 Dec 1995 07:29:13 -0800 (PST) Received: (from shaver@localhost) by neon.ingenia.com (8.6.12/8.6.9) id KAA07214; Thu, 7 Dec 1995 10:31:15 -0500 From: Mike Shaver Message-Id: <199512071531.KAA07214@neon.ingenia.com> Subject: Re: selection criteria? To: mjr@iwi.com Date: Thu, 7 Dec 1995 10:31:15 -0500 (EST) Cc: firewalls@GreatCircle.COM In-Reply-To: <199512070329.WAA05922@switchblade.iwi.com> from "Marcus J. Ranum" at Dec 6, 95 10:29:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Thus spake Marcus J. Ranum: > The brightest raw of sunshine I've seen for a while is Sun's success > positioning Java as a bitchin' cool thing and that SECURITY is part > of the bitchin' coolness of it. The fact that they accomplished a > market sell on that fact is good news; it means that people are > learning to ask for systems that are more than spit and glue and > duct tape. Shame is that half of the crap in the groups is about people trying to get around the stuff. Some are obviously 3ll3t krakers, but some geniunely want to do something that they consider safe. Argh. Long battle ahead, guys. Mike -- #> Mike Shaver (shaver@ingenia.com) Information Warfare Division <# #> Chief Tactical and Strategic Officer "Saepe fidelis" <# #> <# #> "I like your game, but we have to change the rules." -- Anon <# #> <# From firewalls-owner Thu Dec 7 13:01:06 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA13446 for firewalls-outgoing; Thu, 7 Dec 1995 12:52:47 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA13433 for ; Thu, 7 Dec 1995 12:52:43 -0800 (PST) Date: Thu, 7 Dec 1995 15:52:58 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951207155258.2021b887@hobbes.orl.mmc.com> Subject: NIST (was re "security a feature") Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Padgett wrote... >ps Just back from NIST key-escrow conference in Gaithersburg. Corporations > who meet IMNSHO logical requirements will be allowed to hold their own > keys (a major posture change). rmck rote: >...at the >possibilty that the government may BY LAW hold the encryption keys to all >private and/or confidentical telecommunications transactions. CLIPPER may >be dead fans but the administration who is pushing this is still very much >alive. Read my lips (well, the above). The gov will not hold my keys, -> I <- (or at least my employer and by extension AmEx/Visa/Mastercard/QVC-HSC/someone of trust) will. THAT is the major posture change. ›B P.fla From firewalls-owner Thu Dec 7 13:25:28 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA05509 for firewalls-outgoing; Thu, 7 Dec 1995 10:22:54 -0800 (PST) Received: from uuneo.neosoft.com (uuneo.neosoft.com [206.109.1.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id KAA05497 for ; Thu, 7 Dec 1995 10:22:49 -0800 (PST) Received: from ris1.UUCP (ficc@localhost) by uuneo.neosoft.com (8.7.3/8.7.1) with UUCP id MAA05256 for GreatCircle.COM!firewalls; Thu, 7 Dec 1995 12:21:17 -0600 (CST) Received: by ris1.nmti.com (smail2.5) id AA14920; 7 Dec 95 12:02:50 CST (Thu) Received: by sonic.nmti.com; id AA32471; Thu, 7 Dec 1995 11:32:56 -0600 From: peter@nmti.com (Peter da Silva) Message-Id: <9512071732.AA32471@sonic.nmti.com.nmti.com> Subject: Re: chroot/setuid vs type enforcement To: smith@sctc.com (Rick Smith) Date: Thu, 7 Dec 1995 11:32:55 -0600 (CST) Cc: peter@nmti.com, smith@sctc.com, anton@the-wire.com, firewalls@GreatCircle.COM In-Reply-To: <199512061906.NAA05993@shade.sctc.com> from "Rick Smith" at Dec 6, 95 01:06:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > > > To be honest, aren't we really discussing a security model for Unix > > > that's been extracted in retrospect? > Peter Da Silva replied: > > Nope. It was pretty obvious to me at UCB in 1980. I believe that CSRG > > understood it too... after all I was just a freshman, they were grad > > students. > But *today* we're interpreting the model in terms of mandatory access > control. You might be. I'm simply asserting that the security model existed. It was obviously not based on the TCSEC model, but it was a pretty carefully designed model subject to the limitations of running on a system where the total size of the kernel, including all static and dynamic data, was limited to 64k. > One reason chroot() is clearly *not* mandatory access control is > because the networking code isn't the only place that chroot() style > protection is broken. What about access to raw devices? What about it? If you don't put the raw devices or leave any setuid executables in the chrooted environment there's no mechanism that will let a program *create* them. Only root can mknod a device, and if you abandon root privileges as soon as you create the chrooted environment, and that environment is clean, there's no way out of it. Yes, root can break out of chroot. But why are you giving a program in there root privileges? Because you want to open a low numbered port! If you don't go around the security mechanism in the first place by creating this new namespace that doesn't let you delegate permissions (by chmodding device nodes, for example) you wouldn't need to have uid 0 programs in chrooted environments in the first place. Again, chroot is a secure mechanism, *if* you're using the security model it was designed for. From firewalls-owner Thu Dec 7 13:43:41 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA05586 for firewalls-outgoing; Thu, 7 Dec 1995 10:24:59 -0800 (PST) Received: from mail1.is.net (mail1.is.net [198.69.24.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA05577 for ; Thu, 7 Dec 1995 10:24:49 -0800 (PST) Received: from mrdata.is.net (mrdata.is.net [198.69.24.6]) by mail1.is.net (8.6.11/8.6.12) with SMTP id NAA18891; Thu, 7 Dec 1995 13:17:57 -0500 Date: Thu, 7 Dec 1995 14:14:27 -0500 (EST) From: Alex Filacchione To: Patrick Drolet cc: firewalls@GreatCircle.COM Subject: Re: Filtering fragmented IP frames In-Reply-To: <199512042118.QAA01426@CyberSecure.Com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Mon, 4 Dec 1995, Patrick Drolet wrote: > > The problem filtering TCP/IP is fragmentation; How does a firewall (or even a > Cisco Secure Router) manage to filter fragmented IP frames knowing that the > TCP or UDP header is only on the first frame ? > I think your best bet is to filter on the first fragment (FO=0). Note, I mean FO=0, and NOT the first fragment to arrive. You can let the others through if you want, since if FO=0 is filtered out they won't be able to reassemble. Why do you want to filter out FO=0? Well, when the packet is so small that the ENTIRE TCP/IP header is not included (iow, some gets pushed into FO=1) then you want to throw that packet away, otherwise, the info in FO=1 *may* overwrite the header data in FO=0 and change the nature of the packet entirely. By that time, they are already inside. This leads me to something else... Anyone know which software will let you (all? None?) assemble the fragmented packets AT the firewall (in a cache of sorts) or gateway, and then examine them and subject them to normal filtering rules? Thanks, Brain21 brain21@ninja.techwood.org alexf@is.net From firewalls-owner Thu Dec 7 13:54:20 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA14960 for firewalls-outgoing; Thu, 7 Dec 1995 13:22:40 -0800 (PST) Received: from uuneo.neosoft.com (uuneo.neosoft.com [206.109.1.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id NAA14955 for ; Thu, 7 Dec 1995 13:22:35 -0800 (PST) Received: from ris1.UUCP (ficc@localhost) by uuneo.neosoft.com (8.7.3/8.7.1) with UUCP id PAA24408 for GreatCircle.COM!firewalls; Thu, 7 Dec 1995 15:16:24 -0600 (CST) Received: by ris1.nmti.com (smail2.5) id AA21071; 7 Dec 95 15:09:50 CST (Thu) Received: by sonic.nmti.com; id AA18587; Thu, 7 Dec 1995 14:39:55 -0600 From: peter@nmti.com (Peter da Silva) Message-Id: <9512072039.AA18587@sonic.nmti.com.nmti.com> Subject: Re: NT Security and NTFS To: jwojn@telxon.mis.telxon.com (Wojno Jim) Date: Thu, 7 Dec 1995 14:39:55 -0600 (CST) Cc: firewalls@GreatCircle.COM In-Reply-To: <9512071332.AA20200@telxon.mis.telxon.com> from "Wojno, Jim" at Dec 7, 95 08:27:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > While the scenario you describe below does seem like a large loophole, it is > no more so than on most of the OS's I've worked with. Yeh, but these other operating systems vendors don't claim otherwise. From firewalls-owner Thu Dec 7 14:12:54 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA05906 for firewalls-outgoing; Thu, 7 Dec 1995 10:32:38 -0800 (PST) Received: from main.geminisecure.com (main.geminisecure.com [205.179.16.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA05893 for ; Thu, 7 Dec 1995 10:32:32 -0800 (PST) Received: (from leonard@localhost) by main.geminisecure.com (8.6.9/8.6.9) id KAA10243; Thu, 7 Dec 1995 10:26:49 -0800 Date: Thu, 7 Dec 1995 10:26:45 -0800 (PST) From: Leonard Miyata To: Rick Smith cc: firewalls@greatcircle.com, smith@sctc.com Subject: Re: FW: A1 Systems? In-Reply-To: <199512052120.PAA12919@shade.sctc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Tue, 5 Dec 1995, Rick Smith wrote: > Leonard Miyata writes: > > >A Guard basicly takes blocks of Data from Multiple Single Level Ports, > >labels and cryptoseals them, and passes them to a Multi Level Secure > >port. Incoming Data blocks from the MLS port are then checked against the > >internal write up rules, as well as the appropriate seal and label checks > >and passed to the correct MSL Port. > > This sound more like an encryption unit than a Guard. Network level > encryption units take packets or messages from one security context > and protect it from disclosure (and maybe modification) before > releasing it to another. People on the output side can't use the > information released by the encryption unit -- it must be delivered to > another unit that decrypts it. The guards I'm familiar with (SNS Mail > Guard, ACCAT Guard, etc) take information from one security context > and verify that it can be released to the other security context in a > *usable* state. The security issues are *much* tougher for the site, > the guard, and the machines that generate data the guard must pass > judgement on. And it's much more like what a firewall usually does. > > Rick. > smith@sctc.com secure computing corporation > Our IP Guard is heavily dependent on encryption for its functions. The difference is that the IP Guard uses encryption not for data security, but for site to site authentication, as well as integrity, based on the concept of shared secrets between two 'registered' site to site connections. To break the embedded security label/crypto seal in each packet, you have to be good at cracking DES keys, or be successful with trying to covertly sqeeze data from a A-1 platform The current model does not actually encrypt the DATA because it was designed to be exportable. And even though DES is allowed to be exported for authentication purposes, We still need a case by case approval for export. I understand that this will change with our next model, using a different set of keys for data encryption The Guard functionality is with the seperation of incoming DATA according to the security label to the proper protected LAN port, as well as Audit for all events counter to it's list of registered connections Personal Opinions provided by Leonard Miyata aka leonard@geminisecure.com GEMINI COMPUTERS INC. Web page http://www.geminisecure.com From firewalls-owner Thu Dec 7 14:31:33 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA12734 for firewalls-outgoing; Thu, 7 Dec 1995 12:42:27 -0800 (PST) Received: from tuna.wang.com (tuna.wang.com [150.124.136.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA12729 for ; Thu, 7 Dec 1995 12:42:20 -0800 (PST) Received: from mail.wangfed.com (ns.wangfed.com [159.94.10.19]) by tuna.wang.com (8.6.12/8.6.12tf1) with SMTP id PAA16638 for ; Thu, 7 Dec 1995 15:43:20 -0500 Received: from hfsi.hfsi.com by mail.wangfed.com (1.37.109.4/A.09.00a) id AA04509; Thu, 7 Dec 95 15:35:31 -0600 Received: from [159.94.14.48] by hfsi (BULL 5.61++/B.O.S 02.01) id AA00358; Thu, 7 Dec 95 15:33:05 -0500 Date: Thu, 7 Dec 95 15:33:05 -0500 Message-Id: <9512072033.AA00358@hfsi> From: "K Goertzel" Reply-To: "K Goertzel" To: firewalls@GreatCircle.COM Subject: Re: Firewall Selection Criteria Sender: firewalls-owner@GreatCircle.COM Precedence: bulk A firewall is not a telephone. Even after you configure it, you can't just plug it in and walk away and expect it to do it's job. Unless you're willing to put the resources necessary into *managing* your network's security -- including intelligently analysing the firewall's audit trails and doing periodic updates of your risk analysis, particularly as your network configuration changes (e.g., new services, new network connections, new users), you might as well not bother with a firewall or any security countermeasures. Security is not something that comes in a self-contained black box. It is an attribute of how you do business, and as such needs to be managed carefully. Karen Goertzel Manager, International Programmes and Special Projects Secure Systems and Services Operation Wang Federal, Inc. 7900 Westpark Drive - MS 700 McLean, Virginia 22102-4299 TEL: 703-827 3914 FAX: 703-827 3161 Internet: goertzek@wangfed.com +-----------------------------------------+ | Human history becomes more and more a | | race between education and catastrophe. | | - H.G. Wells | +-----------------------------------------+ From firewalls-owner Thu Dec 7 14:33:08 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA14253 for firewalls-outgoing; Thu, 7 Dec 1995 13:09:16 -0800 (PST) Received: from interlock.mgh.com (interlock.mgh.com [152.159.1.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA14248 for ; Thu, 7 Dec 1995 13:09:07 -0800 (PST) From: dnewman@mcgraw-hill.com Received: by interlock.mgh.com id AA02301 (InterLock SMTP Gateway 3.0 for firewalls@greatcircle.com); Thu, 7 Dec 1995 16:09:51 -0500 Message-Id: <199512072109.AA02301@interlock.mgh.com> Received: by interlock.mgh.com (Protected-side Proxy Mail Agent-1); Thu, 7 Dec 1995 16:09:51 -0500 Date: Thu, 07 Dec 95 15:53:26 EDT To: firewalls@greatcircle.com Subject: Re: TokenRing Firewalls Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >In some mail from Rob MacDonald, sie said: >> >> ((snip)) >> >> I have recently joined this group in hopes of seeing how to protect our >> network(s). In all the conversations I have been following, I have only >> seen refernces to Ethernet. I am wondering if there are any TokenRing >> based firewall packages? We are mostly TR with some Ethernet. We do have >> a couple of Cisco routers (2500 & 4000's). We are TR attached to our service >> provider thru the 2500. Any comments would be appreciated. >The link layer (Token Ring/Ethernet/PPP) should not make any >difference to >your firewall. If you go for the proxy firewall, it makes 0 difference, >only some packet filter types might have trouble if they've only been >implemented to support Ethernet frames. ie it won't be of concern to your >ciscos if you include them as part of your firewall. Source route bridging is far more prevalent in token ring shops than Ethernet ones. Having seen much ink spilled on the security problems that source routing introduces, I'd be curious to learn how vendors of token ring-capable firewalls deal with the issue. Is the answer simply to block all SRB frames? Is that a secure enough and flexible enough? Regards David Newman >darren From firewalls-owner Thu Dec 7 14:47:38 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA16827 for firewalls-outgoing; Thu, 7 Dec 1995 13:56:22 -0800 (PST) Received: from lehman.Lehman.COM (Lehman.COM [192.147.66.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA16816 for ; Thu, 7 Dec 1995 13:56:05 -0800 (PST) Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id QAA18386 for ; Thu, 7 Dec 1995 16:56:59 -0500 Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3) id tmp018379; Thu Dec 7 16:56:36 1995 Received: from kublai.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA02991; Thu, 7 Dec 95 16:56:35 EST Received: from badger.lehman.com by kublai.lehman.com (4.1/Lehman Bros. V1.6) id AA19831; Thu, 7 Dec 95 16:56:33 EST Received: by badger.lehman.com (SMI-8.6/Lehman Bros. V1.5) id QAA01809; Thu, 7 Dec 1995 16:56:32 -0500 Date: Thu, 7 Dec 1995 16:56:32 -0500 Message-Id: <199512072156.QAA01809@badger.lehman.com> To: firewalls@greatcircle.com Subject: Remote dialin IP encryption products? From: "Richard Basch" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I have been having difficulty identifying various vendors that offer solutions for providing IP encryption products that can accomodate the following design. I can't imagine there wouldn't be other customers who would also not want to see this either. We want to extend our facilities to provide general IP connectivity from the employees' home/travel systems into our corporate network. We do not want to have any service providers being able to snoop/tamper with the data between the end systems and the corporate network. In essence, we are looking for a solution that provides end-to-end encryption from the various flavors of home systems into the corporate network. We wish to use PPP with CHAP authentication, and possibly augment the authentication process with some other challenge-response/token system. In addition, we want all the data between the end system and the gateway system into the corporate network to be encrypted, preferably including the IP headers (and re-encapsulating the entire packet in another IP/IP packet directed to the gateway host, so as to even prevent traffic analysis, but we'll settle for IP payload encrFrom firewalls-owner Thu Dec 7 19:24:20 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id SAA00935 for firewalls-outgoing; Thu, 7 Dec 1995 18:24:31 -0800 (PST) Received: from iconz.co.nz (iconz.co.nz [202.14.100.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id SAA00896 for ; Thu, 7 Dec 1995 18:24:15 -0800 (PST) Received: from un04.UUCP (Upst@localhost) by iconz.co.nz (8.6.12/8.6.10) with UUCP id PAA10493 for firewalls@greatcircle.com; Fri, 8 Dec 1995 15:25:09 +1300 Received: from manukau.govt.nz (wpsmtp.manukau.govt.nz) by un04.manukau.govt.nz with SMTP (1.37.109.16/16.2) id AA104256351; Fri, 8 Dec 1995 14:32:31 +1300 Received: from INTERNALIP-Message_Server by manukau.govt.nz with Novell_GroupWise; Fri, 08 Dec 1995 14:31:31 +1200 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 08 Dec 1995 13:56:15 +1200 From: Matthew Thompson To: firewalls@greatcircle.com Subject: RE: NT Security and NTFS -Reply Sender: firewalls-owner@GreatCircle.COM Precedence: bulk If you can physically access the box and reboot it you can do anything you want with Unix, Netware or anything else. B level security and Type Enforcement don't help against binary disk editors. Encryption of disk data would. Try this as a plan. Down your favorite unix box, open the case, plug the root disk into your DOS notebook with PCMCIA SCSI adaptor. Get a disk editor such as norton and search the raw disk for the word "root". once you find the password entry zero it out, and reboot. ( or just mount it on another system which you are already root on or boot recovery media like DAT or CDROM if your vendor supports this ) . ON NT, take the disk and plug it into the above mentioned notebook now running NT on which you are administrator and view all files. (or reinstall NT over the top of the current installation). ON Netware, boot off floppy, search for the directory entry for the bindery files, overwrite the first byte of each bindary file, reboot the server. it will assume the bindery is corrupt and create a new one with null password for supervisor. Or, assuming the file server console is not locked (bad move) just load an NLM which creates you a new supervisor equivalent account. The method used here to break these systems are crude physical attacks. They require physical access to the box and disrupt it's normal operation. However what this really goes to show is that if the user has physical access to your Unix, NT, Netware server, then they can do to it what they will, even steal the whole damn thing if they want. There is no way to defend against these sort of attacks on the systems described, just ensure that the user cannot get physical access to the system. Lock it in a room, guard it, encrypt the disks and require a boot password to unencrypt, build this into the disk controller, or place in under the user's desk in a locked safe, with only keyboard and monitor cables coming out, make it explode if tampered with :) The real question is how easy is it to subvert the system when you don't have physical access to it, because there's certainly no challange when you do have physical access. Best Regards, Matthew Thompson From firewalls-owner Thu Dec 7 20:54:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA07275 for firewalls-outgoing; Thu, 7 Dec 1995 20:40:38 -0800 (PST) Received: from eagle.wd.cubic.com ([149.63.94.9]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id UAA07265 for ; Thu, 7 Dec 1995 20:40:34 -0800 (PST) Received: (mischler@localhost) by eagle.wd.cubic.com (8.6.9/8.3) id VAA05092; Thu, 7 Dec 1995 21:27:25 -0800 Date: Thu, 7 Dec 1995 21:27:25 -0800 From: Dave Mischler Message-Id: <199512080527.VAA05092@eagle.wd.cubic.com> To: basch@lehman.com, firewalls@GreatCircle.COM Subject: Re: Remote dialin IP encryption products? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I have an implementation of RFC 1827 Encrypted Security Payload with RFC 1829 DES-CBC Transform that operates in IP tunnel mode. This is provided as a tunnel interface in IPRoute, my shareware IP router that runs on PCs and provides address translation & packet filtering. Send mail to IPRoute@Mischler.COM if you are interested. From firewalls-owner Thu Dec 7 21:24:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA08163 for firewalls-outgoing; Thu, 7 Dec 1995 21:09:15 -0800 (PST) Received: from deimos (pm085-26.dialip.mich.net [141.217.128.216]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id VAA08085 for ; Thu, 7 Dec 1995 21:06:43 -0800 (PST) Received: (from root@localhost) by deimos (8.6.10/8.6.9) id AAA00217; Fri, 8 Dec 1995 00:05:45 -0500 Date: Fri, 8 Dec 1995 00:04:24 -0500 (EST) From: root Reply-To: zerucha@shell.portal.com To: firewalls@GreatCircle.COM Subject: Re: ftp & PASV In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk The PASV is *not* required if the ftp client is properly socksified. I had to fidget with both the one included with SSLeay (which worked, but I had to pick a port (instead of using 0 to let the system pick it), and make sure SHORTENED_RBIND was off since it was so in our server. I also did this with Lynx 2-4-fm which I now have doing socks optionally, but it also transfers properly through our socks server. zerucha@shell.portal.com finger zerucha@jobe.portal.com for PGP key On Thu, 7 Dec 1995, Alex Filacchione wrote: > > > On Fri, 1 Dec 1995, Sten Drescher wrote: > > > Well, the SOCKS ftp client uses (I think) the PASV command to > > tell the ftp server to use passive TCP ports for transfers. That is, > > rather than the ftp server creating the connection to the client, it > > opens a port, tells the client what port to connect to, and waits for > > the client to create the connection. This way, the connection is > > originating inside the SOCKS firewall, instead of outside it. > > > There are ftp clients/servers who do not understand the PASV command. > Anyone know how prevalent these are, and if this is something to be > worried about? IOW, should I set up an ftp that issues the PASV command, > or should I use something like relay and have it sent to other ports, and > what problems would this cause? Obviously the incoming ftp call would > have to come to the gateway or firewall running relay. What are the > configuration issues w/ this? > > Thanks, > > Brain21 > > FailureReason: MailEx0105: Unable to deliver message to cc:Mail. > IntendedRecipient: firewalls@GreatCircle.COM at UNIXGATE@ccMail > > > From firewalls-owner Thu Dec 7 21:33:26 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA06860 for firewalls-outgoing; Thu, 7 Dec 1995 20:28:03 -0800 (PST) Received: from incog.com (ns.incog.com [199.190.177.251]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id UAA06851 for ; Thu, 7 Dec 1995 20:27:58 -0800 (PST) From: mulligan@future.incog.com Received: from future.incog.com by incog.com (SMI-8.6/94082501) id UAA05361; Thu, 7 Dec 1995 20:27:25 -0800 Received: from future by future.incog.com (SMI-8.6/SMI-SVR4) id VAA01677; Thu, 7 Dec 1995 21:28:52 -0700 Message-Id: <199512080428.VAA01677@future.incog.com> To: Paul Traina cc: alexf@is.net (Alex Filacchione), Patrick Drolet , firewalls@GreatCircle.COM Subject: Re: Filtering fragmented IP frames Reply-to: mulligan@incog.com In-reply-to: Your message of "Thu, 07 Dec 1995 14:27:26 PST." <199512072227.OAA27112@puli.cisco.com> Date: Thu, 07 Dec 1995 21:28:52 -0700 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk screend doesn't do any reassembly. It does have a fragment cache so that it can drop or pass fragment trailers if it dropped or passed the fragment leader. This keeps you from wasting bandwidth with fragements that wont reassemble and the associated icmp errors and the end system resources and closes a possible communications channel of just passing fragment tailers but it doesn't really help in the fragment filtering problem. geoff From firewalls-owner Thu Dec 7 22:54:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id WAA12575 for firewalls-outgoing; Thu, 7 Dec 1995 22:46:40 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id WAA12570 for ; Thu, 7 Dec 1995 22:46:36 -0800 (PST) Received: from splinter.rtp.dg.com by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA07307; Fri, 8 Dec 1995 01:47:35 -0500 Received: by splinter (8.6.10/rtp-s04) id GAA18504; Fri, 8 Dec 1995 06:46:27 GMT From: spencerj@dg-rtp.dg.com (Jon Spencer) Message-Id: <199512080646.GAA18504@splinter> Subject: Re: Orange Book Irrelevant (was: A1 Systems?) To: goertzek@wangfed.com Date: Fri, 8 Dec 95 1:46:24 EST Cc: firewalls@GreatCircle.COM In-Reply-To: <9512072012.AA00200@hfsi>; from "K Goertzel" at Dec 7, 95 3:12 pm X-Mailer: ELM [version 2.3 PL11] Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > > In message <199512031701.MAA09764@psyche.the-wire.com> Anton J Aylward writes: > > > The military ideas of "need to know", "heirarchy" and cells don't > > apply in business. > > I might agree that the idea of "hierarchy" (by which, I presume, you mean > classification levels) doesn't apply in business, hmmmmmmm ..... So all that junk on the bottom of corporate documents, such as "Company Confidential" and "Confidential Restricted" are not hierarchical? While consulting at IBM, I wrote documents that I was not allowed to see, and IBM had three hierarchical levels of classifications. This is enither unique nor inappropriate. > but ask the Personnel Director > of any company whether he feels the firm's cleaning crew need to have access to > company personnel records, or ask the company's Chief Counsel whether the > company's sales force have any business browsing the firm's legal files, and you > will see that the idea of "need to know" is just as applicable in business as it > is in the military. There is little unique about the military, as the writer aptly points out here. Researchers are not allowed to see personnel records by corporate security policy. Personnel staff are not allowed to see research results. Corporate confidential info is not allowed to be sent out in the clear on the Internet (two distinct hierarchical classifications. etc ... -- Jon F. Spencer spencerj@rtp.dg.com (uunet!rtp.dg.com!spencerj) Data General Corp. Phone : (919)248-6246 62 T.W. Alexander Dr, MS #119 FAX : (919)248-6108 Research Triangle Park, NC 27709 Office RTP 121/9 Reality is an illusion - perception is what counts. No success can compensate for failure at home. President David O. McKay ***** UCC 1-207 ******** From firewalls-owner Thu Dec 7 23:24:20 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id WAA12446 for firewalls-outgoing; Thu, 7 Dec 1995 22:42:35 -0800 (PST) Received: from hosaka.smallworks.com (hosaka.SmallWorks.COM [192.207.126.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id WAA12431 for ; Thu, 7 Dec 1995 22:42:30 -0800 (PST) Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA09089; Fri, 8 Dec 1995 00:43:24 -0600 Date: Fri, 8 Dec 1995 00:43:24 -0600 From: jim@SmallWorks.COM (Jim Thompson) Message-Id: <9512080643.AA09089@hosaka.smallworks.com> To: cjolley@iac.net, janken@rust.net Subject: Re: Tacacs+ or Radius, that is the question. Cc: firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > I just came from the Novi, Michigan Ameritch/CISCO Seminar. I believe they > said Radius to run under 11.1 IOS (Feb, 96). Lets see if Paul agrees. Its a true statement. From firewalls-owner Fri Dec 8 01:24:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id BAA15640 for firewalls-outgoing; Fri, 8 Dec 1995 01:11:04 -0800 (PST) Received: from myall.awadi.com.au (myall.awadi.com.AU [150.207.2.65]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id BAA15635 for ; Fri, 8 Dec 1995 01:10:59 -0800 (PST) Received: from bunya.awadi ([150.207.2.63]) by myall.awadi.com.au (8.7.1/8.7.1) with SMTP id TAA27728; Fri, 8 Dec 1995 19:41:57 +1030 (CST) Received: from mallee.awadi by bunya.awadi (5.x/SMI-SVR4) id AA04620; Fri, 8 Dec 1995 19:41:44 +1030 From: blymn@awadi.com.au (Brett Lymn) Message-Id: <9512080911.AA04620@bunya.awadi> Subject: Re: NT Security and NTFS To: jeremyp@gsms01.alcatel.com.au (Peter Jeremy) Date: Fri, 8 Dec 1995 19:41:46 +1030 (CST) Cc: firewalls@greatcircle.com In-Reply-To: <199512072013.HAA13808@gsms01.alcatel.com.au> from "Peter Jeremy" at Dec 8, 95 07:13:32 am X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk According to Peter Jeremy: > >Sun's and many PC's allow you to install a password in the PROM monitor/BIOS >which prevents you re-booting the machine without the relevant password. >This helps prevent the above. > The only problem with the scheme for both these machines is that if the OS allows you access to the eeprom memory then the password is there in the clear. -- Brett Lymn, Computer Systems Administrator, AWA Defence Industries =============================================================================== "Upgrading your memory gives you MORE RAM!" - ad in MacWAREHOUSE catalogue. From firewalls-owner Fri Dec 8 02:26:04 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id BAA16434 for firewalls-outgoing; Fri, 8 Dec 1995 01:59:28 -0800 (PST) Received: from isgate.is (isgate.is [193.4.58.51]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id BAA16423 for ; Fri, 8 Dec 1995 01:59:19 -0800 (PST) Received: from bsp.is by isgate.is (8.6.10/ISnet/14-10-91); Fri, 8 Dec 1995 10:00:02 GMT Received: by bsp.is (5.65c8/IDA-1.4.4); Fri, 8 Dec 1995 09:59:53 GMT From: ragnar@bsp.is (Finnbogi Ragnar Ragnarsson) Message-Id: <199512080959.AA19026@bsp.is> Subject: Re: NT Security and NTFS To: firewalls@GreatCircle.COM Date: Fri, 8 Dec 1995 09:59:53 +0000 (WET) In-Reply-To: <199512072013.HAA13808@gsms01.alcatel.com.au> from "Peter Jeremy" at Dec 8, 95 07:13:32 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text X-Charset: LATIN1 X-Char-Esc: 29 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Jeremy writes: > > Jim Wojno writes: > > On Sun systems, as > >well as Sequent machines, if a person has the install CD-ROM or tape and has > >physical access to that machine, they can boot to miniroot. Once done, the > >filesystem can be mounted and accessed without a password, > Sun's and many PC's allow you to install a password in the PROM monitor/BIOS > which prevents you re-booting the machine without the relevant password. > This helps prevent the above. But then many PCs today have FLASH BIOSes ;) in case where you are able to run something on the PC. Would it be possible to let a modified BIOS trigger a program or send data through the network card? I would think so. Firewall is only a part of security. Physical security is another part. > > PROM monitor passwords also prevent users from fiddling with their proc > areas... > > > The key to preventing this would be to ensure > >limited access to the machine in question. > And whilst you are planning the physical security, don't forget the > backup tapes. Unless you encrypt your backups, there's nothing stopping > someone from reading the files off the tapes. > You should also keep backups in another physical location, in case of fire or another disaster. How many of you DO keep backups in a different physical location? > Also, arranging physical security can be more difficult for workstations, > which are normally found in a normal office environment. It's a question of who do you trust and how far you want to go. You have to make somewhere a compromise. From firewalls-owner Fri Dec 8 02:54:27 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA17118 for firewalls-outgoing; Fri, 8 Dec 1995 02:28:59 -0800 (PST) Received: from crc.u-strasbg.fr (crc.u-strasbg.fr [130.79.200.20]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id CAA17060 for ; Fri, 8 Dec 1995 02:26:46 -0800 (PST) Received: from crc (localhost [127.0.0.1]) by crc.u-strasbg.fr (8.6.11/8.6.9) with SMTP id LAA21643 for ; Fri, 8 Dec 1995 11:22:41 +0100 Message-ID: <30C811F1.94B@crc-u.strasbg.fr> Date: Fri, 08 Dec 1995 11:22:41 +0100 From: Laurent Balzinger - Centre Reseau Communication - Universite Louis Pasteur Organization: Universite Louis Pasteur Centre Reseau Communication X-Mailer: Mozilla 2.0b3 (X11; I; SunOS 5.4 sun4m) MIME-Version: 1.0 To: firewalls@GreatCircle.COM Subject: TIS and Screend Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hi, Does anybody know if screend and TIS work fine together on a dual home gw with Linux? Thanks for any experience. Laurent From firewalls-owner Fri Dec 8 03:24:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA17227 for firewalls-outgoing; Fri, 8 Dec 1995 02:30:14 -0800 (PST) Received: from pegase.total.fr (pegase.total.fr [146.249.152.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id CAA17182 for ; Fri, 8 Dec 1995 02:29:47 -0800 (PST) Received: from tidtest.total.fr by pegase.total.fr with SMTP (16.6/16.2) id AA12496; Fri, 8 Dec 95 11:24:02 +0100 Received: by tidtest.total.fr (4.1/SMI-4.1) id AA20202; Fri, 8 Dec 95 11:29:36 GMT Message-Id: <9512081129.AA20202@tidtest.total.fr> To: "A. Padgett Peterson, P.E. Information Security" Cc: firewalls@greatcircle.com Subject: Re: re "security a feature" In-Reply-To: Your message of "Wed, 06 Dec 1995 11:20:16 EST." <951206112016.20217758@hobbes.orl.mmc.com> Date: Fri, 08 Dec 1995 11:29:36 +0000 From: Michel Lavondes Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In message <951206112016.20217758@hobbes.orl.mmc.com>, "A. Padgett Peterson, P. E. Information Security" writes: > > [snip] > > - still trying to consolodate my thoughts but went in hopeful and came > away optomistic. optomistic : one who sees the world through a mist (or is it misty-eyed ?) :-) Michel Lavondes (lavondes@tidtest.total.fr) #include ============================================================ = When Privacy Is Outlawed, Only Outlaws Will Have Privacy = = I Support the Phil Zimmermann Legal Defense Fund! = = email: zldf@clark.net http://www.netresponse.com/zldf = ============================================================ (with thanks to those who lead me into it :-)) From firewalls-owner Fri Dec 8 03:54:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA17674 for firewalls-outgoing; Fri, 8 Dec 1995 02:46:05 -0800 (PST) Received: from relay-1.mail.demon.net (relay-1.mail.demon.net [158.152.1.140]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id CAA17669 for ; Fri, 8 Dec 1995 02:45:56 -0800 (PST) Received: from gate.demon.co.uk by relay-1.mail.demon.net id sg.aa04992; 8 Dec 95 10:46 GMT Received: by reednews.co.uk (5.x/SMI-SVR4) id AA05452; Fri, 8 Dec 1995 10:48:21 GMT From: Gavin Aiken Message-Id: <9512081048.AA05452@reednews.co.uk> Subject: Pre-forking Proxies? To: firewalls@greatcircle.com Date: Fri, 8 Dec 1995 10:48:19 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SMTP-Posting-Host: gate.demon.co.uk [Fri, 8 Dec 95 10:46:52 GMT] Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I have implemented firewalling at our site using various components from the TIS toolkit. I have also set up several web servers, and have used the NCSA httpd (ver1.5). I have been very impressed with the high speed and throughput of the NCSA httpd, which saves cpu cycles by running apart from inetd. This means it doesn't have to read in its config files each time a new connection is initiated, for example. Now to get to my question, or problem. I have a large and growing demand for access to the http-gw proxy service from our internal network, as more and more of our users are deemed as _needing_ access to the internet. http-gw runs under inetd - so each new connection demands that inetd starts off a new http-gw process, which must then read the firewall configuration table before deciding whether its going to allow the user access, or whatever. Does anyone know of any other proxy code that can run in a pre-forking configuration, similar to NCSA's httpd? Or does anyone have a view on hacking http-gw? Can anyone see any obvious security holes in attempting to do this? Or should I just convince management to buy a more powerful machine for the firewall, thus obviating the need to worry about cpu cycles :-) ? Comments and help acknowledged in advance. -- Gavin Aiken | IT Dept, RRN Lancs | http://www.reednews.co.uk Newspaper House | Work: +44 1254 678678 High Street | Fax: +44 1254 673347 Blackburn | Home: +44 1254 812956 _________________________________________________________ *finger gavin@theboard.reednews.co.uk for PGP Public Key* From firewalls-owner Fri Dec 8 04:54:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id EAA20677 for firewalls-outgoing; Fri, 8 Dec 1995 04:36:02 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id EAA20672 for ; Fri, 8 Dec 1995 04:35:54 -0800 (PST) Message-Id: <199512081235.EAA20672@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA147076023; Fri, 8 Dec 1995 23:33:43 +1100 From: Darren Reed Subject: Re: Filtering fragmented IP frames To: alexf@is.net (Alex Filacchione) Date: Fri, 8 Dec 1995 23:33:43 +1100 (EDT) Cc: pdrolet@CyberSecure.Com, firewalls@GreatCircle.COM In-Reply-To: from "Alex Filacchione" at Dec 7, 95 02:14:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In some mail from Alex Filacchione, sie said: [...] > This leads me to something else... > > Anyone know which software will let you (all? None?) assemble the > fragmented packets AT the firewall (in a cache of sorts) or gateway, and > then examine them and subject them to normal filtering rules? Packet filters (ie routers) should not be trying to reassemble packets. Problem: two routers are passing packets to each other and have n-1 fragments in their cache and their buffers are full. They can't dequeue all the fragments because they don't have them all. It is well known if you send a machine too many fragments, it'll lock up (run out of buffer space), why make it worse fo routers ? darren From firewalls-owner Fri Dec 8 05:54:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA22464 for firewalls-outgoing; Fri, 8 Dec 1995 05:32:55 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id FAA22440 for ; Fri, 8 Dec 1995 05:32:48 -0800 (PST) Message-Id: <199512081332.FAA22440@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA153629570; Sat, 9 Dec 1995 00:32:50 +1100 From: Darren Reed Subject: Re: Remote dialin IP encryption products? To: mischler@eagle.wd.cubic.com (Dave Mischler) Date: Sat, 9 Dec 1995 00:32:50 +1100 (EDT) Cc: basch@lehman.com, firewalls@GreatCircle.COM In-Reply-To: <199512080527.VAA05092@eagle.wd.cubic.com> from "Dave Mischler" at Dec 7, 95 09:27:25 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In some mail from Dave Mischler, sie said: > > I have an implementation of RFC 1827 Encrypted Security Payload with > RFC 1829 DES-CBC Transform that operates in IP tunnel mode. This > is provided as a tunnel interface in IPRoute, my shareware IP router > that runs on PCs and provides address translation & packet filtering. > > Send mail to IPRoute@Mischler.COM if you are interested. Discussion on the IP Security protocol (of which this is one proposal) can be found on ipsec@ans.net. RFCs (at this stage) are still early in the life of the standards tracks and the final choice is yet to be made, although there has been some strong criticism of SKIP. On that note, which other implementations of those RFCs does your product interoperate with ? There was some being done at the Dallas IETF (but that may have just been the SKIP guys), which I assume you were at... darren From firewalls-owner Fri Dec 8 07:23:50 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA24306 for firewalls-outgoing; Fri, 8 Dec 1995 06:42:14 -0800 (PST) Received: from net4.sbic.co.za (net4.sbic.co.za [160.117.116.51]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA24294 for ; Fri, 8 Dec 1995 06:41:46 -0800 (PST) From: Cameron_A_P@ceo.sbic.co.za Received: from zork.sbic.co.za by net4.sbic.co.za (5.x/SMI-SVR4) id AA00904; Fri, 8 Dec 1995 16:43:13 -0200 Received: by zork.sbic.co.za (1.00/net4) id AA00090; Fri, 8 Dec 95 16:40:28+2 Date: Fri, 8 Dec 95 16:40:28+2 Message-Id: <9512082140.AA00090@zork.sbic.co.za> To: firewalls@greatcircle.com Subject: X.25 Firewall Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Message: What firewalls are there that can handle X.25, SNA and TCP/IP. Thanks In Anticipation From firewalls-owner Fri Dec 8 07:24:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA24335 for firewalls-outgoing; Fri, 8 Dec 1995 06:44:43 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA24330 for ; Fri, 8 Dec 1995 06:44:39 -0800 (PST) Date: Fri, 8 Dec 1995 9:40:51 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951208094051.2021c254@hobbes.orl.mmc.com> Subject: Caveat Emptor Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >Instead of expecting vendors to be anything other than what they are, we'd all >do better to remember a bit of wisdom that goes a long way: >Caveat emptor. In 1979 I bought a J.C.Penney battery for my Sunbird. "Guarenteed for as long as I own my car". Except that now I have to go to a Firestone dealer in another town to get replacement (and guess am lucky I still can). I also have two years to go on the "no questions" warrenty that came with my NCR 3150 notebook. No problem when AT&T bought the company but now that AT&T is out of the business... (been trying to buy a second removable hard drive for it so I can mount BSD for some time. No luck. Even a carrier I can put a drive in would be welcome, *hint*) This industry is rife with promises that are never met: a year ago I bought an Epson 1100 printer partly on the promise that a PostScript module would be available RSN, now am told it will never be available. Am still waiting for a promised "employee purchase plan" for Iomega ZIP drives & media that was announced in April - prices, part numbers, and everything - and since then every month IOMEGA says "next month". Guess the bottom line is "Get it in writing with a delivery date and penalty clause". If you cannot get that do not expect anything that is not immediately delivered & pay accordingly. And this is from "mainstream vendors", add in "Joe's TV Repair and Firewalls" and there is a whole different problem. Anytime you have a lot of money looking for someone to take it, there will be hands outstretched. Do not have a good answer other than either know what you are buying or buy from someone you can trust (assuming you can trust anyone). Be careful out there. Warmly, Padgett From firewalls-owner Fri Dec 8 08:16:18 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA24301 for firewalls-outgoing; Fri, 8 Dec 1995 06:42:04 -0800 (PST) Received: from mlfire.ml.com (mlfire.ml.com [192.246.100.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA24296 for ; Fri, 8 Dec 1995 06:42:00 -0800 (PST) From: John_Reinke_at_NYTRP@pcmailgw.ml.com Received: from commpost.ml.com ([146.125.4.24]) by mlfire.ml.com (8.6.12/8.6.12) with ESMTP id JAA18494; Fri, 8 Dec 1995 09:43:41 -0500 Received: from pcmailgw.ml.com (unixccgw2.pcmailgw.ml.com [146.125.77.67]) by commpost.ml.com (8.6.12/8.6.12) with SMTP id JAA22166; Fri, 8 Dec 1995 09:35:39 -0500 Received: from ccMail by pcmailgw.ml.com (SMTPLINK V2.11 Alpha 1) id AA818444174; Fri, 08 Dec 95 09:39:41 est Date: Fri, 08 Dec 95 09:39:41 est Message-Id: <9511088184.AA818444174@pcmailgw.ml.com> To: firewalls@greatcircle.com, listserv@peach.ease.lsoft.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk While I personally wouldn't advise using it for about five years, someone has put a firewall on NT. Perhaps, even if it is not perfect (i.e., bug free), it could be effective and cheap enough to serve as a "bulkhead" within an internal network. Perhaps others might wish to comment on this news item. ========================================================================= OTC 12/07 1308 NETWORK-1 DEMONSTRATES FIREWALL/PLUS ON WINDOWS/NT SAN FRANCISCO, Dec. 7 /PRNewswire/ -- Network-1 Software and Technology Inc. this week became the first network firewall development company to show a firewall running on a Windows/NT(TM) platform. Network-1 demonstrated a working prototype version of its popular FireWall/Plus(TM) product running on Windows/NT. FireWall/Plus is the first MS-DOS-based commercial firewall which also runs on Windows-95 and Windows/NT. The Windows/NT version will run on both Intel and Alpha processors. The Windows/NT prototype of FireWall/Plus was demonstrated at DECUS '95/San Francisco, the Digital Equipment Computer Users Society trade show and symposium at San Francisco's Moscone Convention Center. "Network-1 is the first to actually show a working prototype of an NT-based firewall," said Robert Russo, president of the New York-based software company. "The Windows/NT version of FireWall/Plus retains the richness of features and robust security facilities found in the MS-DOS version of FireWall/Plus," he said. "We are producing the Windows/NT versions for 64-bit Alpha and Pentium at the same time for different market requirements," said Dr. Bill Hancock, executive vice president of Network-1 and chief product architect of FireWall/Plus. "Customers have differing network sizes and needs in firewall performance. For small and medium sites, the Pentium or Pentium Pro versions of FireWall/Plus on Windows/NT will most likely serve their security needs. For larger sites requiring 100mbps local area network (LAN) support and high-speed WAN connections (such as ATM, frame relay, SMDS, T3, etc.), the Alpha version is capable of supporting very high speed connectivity and rapid rule processing required for high-volume environments," Hancock said. Network-1 Software and Technology Inc. specializes in networking and computer security products and services. In addition to its corporate headquarters in New York, the company has offices in Dallas and in Colorado Springs, Colo. Network-1 plans to ship the completed versions of FireWall/Plus for Windows/NT and Windows-95 by spring. FireWall/Plus for MS-DOS is available now. FireWall/Plus rejects all traffic unless the system or network manager specifically allows it. This method of filtering is considered to be the highest level of security isolation for network firewall products. Once installed on the system and activated (which takes just a few minutes), FireWall/Plus presents the system or network manager with a series of point-and-click set-up options, which allows rapid configuration of the product to suit each customer's specific needs. It can take as little as 10 minutes from activation to use of FireWall/Plus. Through the use of a sophisticated graphical user interface and pre-defined security rule bases, customers with limited technical staffing and skills may implement sophisticated network firewall technology with FireWall/Plus without long-term training or a large technical personnel knowledge base to support the product. Customers interested in testing FireWall/Plus may download a fully functional copy from Network-1's web server at http://www.network-1.com/n1 . An automated license - generation system will allow a two-week test drive of the software. -0- 12/7/95 /CONTACT: Bob Russo of Network-1, 800-638-9751, or 212-293-3068, or Internet - russonetwork-1.com, or Web - http://www.network-1.com/n1 / ========================================================================= This represents my opinion not that of my employer, my wife, nor anyone else that counts. ;-) From firewalls-owner Fri Dec 8 08:27:35 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA24211 for firewalls-outgoing; Fri, 8 Dec 1995 06:39:35 -0800 (PST) Received: from TIS.COM (neptune.tis.com [192.94.214.96]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA24206 for ; Fri, 8 Dec 1995 06:39:31 -0800 (PST) Received: by neptune.TIS.COM id ac21933; 8 Dec 95 9:25 EST Received: from relay.tis.com by neptune.TIS.COM id aa21776; 8 Dec 95 9:16 EST Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.1) id xma013892; Fri, 8 Dec 95 08:50:28 -0500 Received: from jupiter.tis.com by tis.com (4.1/SUN-5.64) id AA25411; Fri, 8 Dec 95 09:16:14 EST From: Jody C Patilla Message-Id: <9512081416.AA25411@tis.com> Subject: Re: NT Security and NTFS To: Finnbogi Ragnar Ragnarsson Date: Fri, 8 Dec 1995 09:16:11 -0500 (EST) Cc: firewalls@greatcircle.com In-Reply-To: <199512080959.AA19026@bsp.is> from "Finnbogi Ragnar Ragnarsson" at Dec 8, 95 09:59:53 am Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > > You should also keep backups in another physical location, in case of fire > or another disaster. > How many of you DO keep backups in a different physical location? More than that, all of you who are keeping your tapes in a safe - is it UL rated for *media*? If it's an ordinary document safe, the steam released at high temperatures will melt your media. - jcp -- ========================================================================= Jody C. Patilla jcp@tis.com Trusted Information Systems Glenwood, Md. From firewalls-owner Fri Dec 8 08:54:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA24136 for firewalls-outgoing; Fri, 8 Dec 1995 06:33:03 -0800 (PST) Received: from services ([168.166.0.67]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA24131 for ; Fri, 8 Dec 1995 06:32:54 -0800 (PST) Received: from services by services (SMI-8.6/SMI-SVR4) id IAA01457; Fri, 8 Dec 1995 08:34:54 -0600 Date: Fri, 8 Dec 1995 08:34:51 -0600 (CST) From: "Frank K. Senter" X-Sender: fsenter@services To: Paul Ferguson cc: dnewman@mcgraw-hill.com, firewalls@GreatCircle.COM Subject: Re: TokenRing Firewalls In-Reply-To: <199512080152.RAA19381@lint.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Wait a minute! You are mixing apples and oranges, and while that's a good basis for fruit salad, it shouldn't be used to say that token ring topology poses problems for firewalls. Source route bridging is TR's MAC layer way of getting communications across the various segments that make up a site's LAN. I think we are talking about TCP/IP firewalls, which would mean that any partitioning of a LAN (or separating a LAN from your Internet providor) calls for distinct IP networks on each side of the firewall, and hence some routing function. SRB is terminated at the router. You won't see an RI field that shows packet A coming from "segment 001 via bridge 1, 002 via *router* XXX.XXX.XXX.XXX". Now, if you want to tell someone that SRB is not scalable and rather stinks in a WAN environment...... Frank Senter Senior Information Specialist Missouri Highway and Transportation Department P.O. Box 270 Jefferson City MO 65102 On Thu, 7 Dec 1995, Paul Ferguson wrote: > At 03:53 PM 12/7/95 EDT, dnewman@mcgraw-hill.com wrote: > > > > >>The link layer (Token Ring/Ethernet/PPP) should not make any >difference to > >>your firewall. If you go for the proxy firewall, it makes 0 difference, > >>only some packet filter types might have trouble if they've only been > >>implemented to support Ethernet frames. ie it won't be of concern to your > >>ciscos if you include them as part of your firewall. > > > > Source route bridging is far more prevalent in token ring shops than > > Ethernet ones. Having seen much ink spilled on the security problems > > that source routing introduces, I'd be curious to learn how vendors of > > token ring-capable firewalls deal with the issue. Is the answer simply > > to block all SRB frames? Is that a secure enough and flexible enough? > > > > Well, I would suggest to you that you simply *not* do SRB at all. > Route the traffic, or if its currently unroutable, migrate to something > that *is* routable. > > Seriously, the framing does enter into the equation in other ways. For > instance, the default frame-type in Netware 3.1x environments was one > thing, now in 4.x it something else. :-) > > However, if its *routed* and not bridged, it becomes much more of a > palatable exercise to filter traffic. I would also suggest that access > control at layer 3 is much less CPU intensive than at layer 2. To > generically state that 'it won't be of concern' is the Wrong Thing. > > My $.02. > > -paul > > > -- > Paul Ferguson || || > Consulting Engineering || || > Reston, Virginia USA |||| |||| > tel: +1.703.716.9538 ..:||||||:..:||||||:.. > e-mail: pferguso@cisco.com c i s c o S y s t e m s > > From firewalls-owner Fri Dec 8 09:05:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA26735 for firewalls-outgoing; Fri, 8 Dec 1995 08:13:48 -0800 (PST) Received: from mail1.is.net (mail1.is.net [198.69.24.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA26730 for ; Fri, 8 Dec 1995 08:13:42 -0800 (PST) Received: from mrdata.is.net (mrdata.is.net [198.69.24.6]) by mail1.is.net (8.6.11/8.6.12) with SMTP id LAA32088; Fri, 8 Dec 1995 11:12:27 -0500 Date: Fri, 8 Dec 1995 12:08:32 -0500 (EST) From: Alex Filacchione To: Bill Husler cc: firewalls@GreatCircle.COM Subject: Re: Firewall Selection Criteria In-Reply-To: <199512070042.AA08648@interlock.mckesson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Wed, 6 Dec 1995, Bill Husler wrote: > >Actually, the drug companies do provide guarantees. If the drug > >has bad side effects or is ineffective, the drug company may be > >held liable. One drug, Thalidomide (sp?), comes immediately to > Hmm, isn't this guarantee independent of anything the drug company would > like to provide? In that way, a firewall company could indeed find itself > in court simply because by marketing a "Secure Firewall" product they are > implying the resistance to break-in. I suppose that unless they specify I think that we are comparing apples and oranges here. If the pharmacist gave you (as a matter of course) the (say) 3 chemicals needed to make up a drug and you had to mix it and cook it yourself with just some instructions, then we could be comparing the same things. Perhaps the pharmacist and a VAR are closer to the same lines. I don't hink that you can sue anyway. Can you sue the people that make Bayer Aspirin if you take it and it does not cure your headache? I don't think that you could sue a firewall manufacturer unless they configure the FW for you, and guarantee you security and safety from breakins. Still, it's apples and oranges, regardless of whether my arguements are right or wrong. Brain21 brain21@ninja.techwood.org alexf@is.net From firewalls-owner Fri Dec 8 09:24:26 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA28180 for firewalls-outgoing; Fri, 8 Dec 1995 09:11:36 -0800 (PST) Received: from galil.austnsc.tandem.com (argyle.mpd.tandem.com [131.124.250.13]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id JAA28166 for ; Fri, 8 Dec 1995 09:11:29 -0800 (PST) Received: (from dreschs@localhost) by galil.austnsc.tandem.com (8.7.1/8.7.1) id LAA01118; Fri, 8 Dec 1995 11:14:40 -0600 (CST) To: Subject: Re: ftp & PASV References: From: dreschs@mpd.tandem.com (Sten Drescher) Date: 08 Dec 1995 11:14:38 -0600 In-Reply-To: root's message of Fri, 8 Dec 1995 00:04:24 -0500 (EST) Message-ID: <55bupjh401.fsf@galil.austnsc.tandem.com> Organization: Tandem Computers Lines: 18 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk root said: r> The PASV is *not* required if the ftp client is properly socksified. r> I had to fidget with both the one included with SSLeay (which worked, r> but I had to pick a port (instead of using 0 to let the system pick r> it), and make sure SHORTENED_RBIND was off since it was so in our r> server. So the ftp client that comes with socks isn't properly socksified? If you meant that you don't have to MANUALLY issue the PASV I'll agree, but otherwise I'd like to know how you get incoming tcp connections through your filewall. -- #include /* Sten Drescher */ To get my PGP public key, send me email with your public key and Subject: PGP key exchange Key fingerprint = 90 5F 1D FD A6 7C 84 5E A9 D3 90 16 B2 44 C4 F3 From firewalls-owner Fri Dec 8 09:54:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA27734 for firewalls-outgoing; Fri, 8 Dec 1995 08:56:57 -0800 (PST) Received: from tuna.wang.com (tuna.wang.com [150.124.136.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA27729 for ; Fri, 8 Dec 1995 08:56:53 -0800 (PST) Received: from mail.wangfed.com (ns.wangfed.com [159.94.10.19]) by tuna.wang.com (8.6.12/8.6.12tf1) with SMTP id LAA01252 for ; Fri, 8 Dec 1995 11:57:53 -0500 Received: from [159.94.10.15] by mail.wangfed.com (1.37.109.4/A.09.00a) id AA10378; Fri, 8 Dec 95 11:50:07 -0600 Received: from [159.94.14.48] by hfsi (BULL 5.61++/B.O.S 02.01) id AA04880; Fri, 8 Dec 95 11:47:46 -0500 Date: Fri, 8 Dec 95 11:47:46 -0500 Message-Id: <9512081647.AA04880@hfsi> From: "KM" Reply-To: "KM" To: firewalls@GreatCircle.COM Subject: Re: Orange Book Irrelevant (was: A1 Systems?) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In message <199512080646.GAA18504@splinter> Jon Spencer writes: > hmmmmmmm ..... So all that junk on the bottom of corporate documents, such > as "Company Confidential" and "Confidential Restricted" are not > hierarchical? While consulting at IBM, I wrote documents that I was not > allowed to see, and IBM had three hierarchical levels of classifications. > This is enither unique nor inappropriate. > There is little unique about the military, as the writer aptly points out > here. Researchers are not allowed to see personnel records by corporate > security policy. Personnel staff are not allowed to see research results. > > Corporate confidential info is not allowed to be sent out in the clear on > the Internet (two distinct hierarchical classifications. The main difference being that for some reason the vast majority of corporations are unwilling to recognise the parallels between their own data sensitivity labels and the idea of "military" hierarchical classifications. It's as if they believe there is something inherent to a multi-level secure system that says not only must it label data, but that the labels it uses can *only* say "Unclassified", "Confidential/Restricted", "Secret", and "Top Secret". I'm convinced the main problem with many civilian and commercial users' refusal to recognise the applicability of Mandatory Access Controls to their own security policies is lack of imagination. They are, bluntly, too blind (either accidentally or intentionally) to see that a system that is built to enforce a MAC policy would be far more useful and appropriate for the way they do business than a DAC-only system which they bend and twist until they force it to look like it's enforcing a MAC policy -- the only difference being they rob themselves of benefitting from the higher level of assurance they'd get if they'd just own up to their requirements and buy the right tool for the job. Karen Goertzel Manager, International Programmes and Special Projects Secure Systems and Services Operation Wang Federal, Inc. 7900 Westpark Drive - MS 700 McLean, Virginia 22102-4299 TEL: 703-827 3914 FAX: 703-827 3161 Internet: goertzek@wangfed.com +-----------------------------------------+ | Human history becomes more and more a | | race between education and catastrophe. | | - H.G. Wells | +-----------------------------------------+ From firewalls-owner Fri Dec 8 10:28:53 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA27588 for firewalls-outgoing; Fri, 8 Dec 1995 08:54:01 -0800 (PST) Received: from Fe3.rust.net (Fe3.rust.net [204.157.12.254]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA27577 for ; Fri, 8 Dec 1995 08:53:55 -0800 (PST) Received: from mh-4.rust.net by Fe3.rust.net via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA21951; Fri, 8 Dec 1995 11:53:10 -0800 Date: Fri, 8 Dec 1995 11:53:10 -0800 Message-Id: <199512081953.LAA21951@Fe3.rust.net> X-Sender: janken@rust.net X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "K Goertzel" From: janken@rust.net (Kenneth J. Stephens) Subject: Re: A1 Systems? Cc: Firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >In message Bob McKisson writes: > >> You mean like the folks who failed to validate the performance of the >> management teams at Wang and Honeywell Federal Systems before they bought >> their stock?...and the government agencies that bought train loads of >> "validated and accredited" TEMPEST systems from those companies? :) >> >> Oh yes indeed. Let's talk about the perfect world of trusted systems and >> vendors claims. :) > >Karen Goertzel replied: > >Instead of expecting vendors to be anything other than what they are, we'd all >do better to remember a bit of wisdom that goes a long way: > >Caveat emptor. > > > > >Karen Goertzel >Manager, International Programmes and Special Projects >Secure Systems and Services Operation >Wang Federal, Inc. >7900 Westpark Drive - MS 700 >McLean, Virginia 22102-4299 >TEL: 703-827 3914 >FAX: 703-827 3161 >Internet: goertzek@wangfed.com > ____ / \ / \ / \ / Beware \ / of Falling \ \ Rants / \ / \ / \ / \____/ || || Do not lower your expectations of vendors! If you ask for less from the vendors they will let their standards slip even lower. Vendor mis- representation problems are only cured by stronger oversite on your part. The vendor can only get away with what you don't see or your management allows through lack of support for your area. Caveat emptor is healthy. Verification of vendor claims/promises is the implementation method for Caveat emptor. ____ / \ / \ / \ / End of \ / of Falling \ \ Rants / \ Zone / \ / \ / \____/ || || Karen, did you cc your boss when you sent the above message? Ken [][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][] [] [] [] Ken Stephens Senior Capacity Planner/Data Security Officer [] [] email: Ken_Stephens@miconsulting.com Voice (313) 876-5081 [] [] Michigan Employment Security Commission (MESC) Fax (313) 876-6827 [] [] 7th Fl. I.S. [] [] 7310 Woodward Ave [] [] Detroit, MI 48202 [] [] [] [] Millennium Consulting Your Security Policy is only [] [] 28234 Diesing Dr. as strong as your organization's [] [] Madison Heights, MI 48071 commitment to it. [] [] [] [][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][] From firewalls-owner Fri Dec 8 10:54:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA29413 for firewalls-outgoing; Fri, 8 Dec 1995 10:03:04 -0800 (PST) Received: from main.geminisecure.com (main.geminisecure.com [205.179.16.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA29408 for ; Fri, 8 Dec 1995 10:02:59 -0800 (PST) Received: (from leonard@localhost) by main.geminisecure.com (8.6.9/8.6.9) id JAA15261; Fri, 8 Dec 1995 09:57:28 -0800 Date: Fri, 8 Dec 1995 09:57:28 -0800 (PST) From: Leonard Miyata To: jpilley@lioninc.com cc: firewalls@GreatCircle.COM Subject: Re: Mathematical Proof of RSA Encryption In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Fri, 8 Dec 1995, Mr.Sunay Gandhi wrote: On Wed, 6 Dec 1995, John Pilley wrote: > Ladies and Gentlemen: > > The asynchronous scheme of encryption/decryption invented by Rivest, Shamir > & Adleman involves the use of multiplicative inverses, a modulus and a > public and secret key chosen/derived from the primes whose product makes up > the modulus. > > Would one of you good people point me towards a proof(?), derivation(?), > explanation(?) showing (Mathematically) how it works? > > Thanks! > John Pilley at InfoSystems Inc. > (509) 328-9108 > The College Professor for my networking class had a simple laymens explanation for how RSA public/private key functions work and are used. Once you have your two keys, you have essentially two functions f(x) and g(x) that are inverse functions. This gives the property that f(g(x))=x and g(f(x))=x. The properties of RSA are such, that if you know the algorithm f(x), it does not tell you what the algorithm of g(x) is. Lets say, two persons want to communicate with non-repudiation (digital signiture). Each person has their pair of keys (F(x), G(x) and f(x), g(x) ) To prove the source and intended destination, the keys ( F(x), and f(x) ) are published in a secure fashion as 'Public' keys. If the letter was being sent from lower case to upper case, the encryption would be done in the following fashion F(g(x)) = y -----> f(G(y))=x Since f(x) is used to decode, It must have been created by the owner of the private key g(x). And Since G(x) decodes it, it must have been intended to be sent to the owner of G(x) private key, since F(x) must have been used to code the message Hope this has been useful Personal opinions provided by Leonard Miyata aka leonard@geminisecure.com GEMINI COMPUTERS INC. Web Page www.geminisecure.com From firewalls-owner Fri Dec 8 11:24:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA00797 for firewalls-outgoing; Fri, 8 Dec 1995 10:44:29 -0800 (PST) Received: from NYXGATE1.btco.com (gate1.btco.com [198.83.51.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id KAA00781 for ; Fri, 8 Dec 1995 10:44:21 -0800 (PST) Received: (from mailer@localhost) by NYXGATE1.btco.com (8.7.1/8.6.9) id NAA00783 for ; Fri, 8 Dec 1995 13:45:09 -0500 (EST) X-Authentication-Warning: NYXGATE1.btco.com: mailer set sender to using -f Received: from nycsex0001.btco.com(138.93.110.203) by NYXGATE1.btco.com via smap (V1.3) id sma010534; Fri Dec 8 13:45:07 1995 Received: (from newsadm@localhost) by NYCSEX0001.btco.com (8.7.1/BTmail) id NAA11177; Fri, 8 Dec 1995 13:45:16 -0500 (EST) To: firewalls@greatcircle.com Path: newsadm From: Guru Sundararaman Newsgroups: btco.list.firewalls Subject: Access to Internal Databases from External Web Server Date: Fri, 08 Dec 1995 13:43:38 -0500 Organization: Bankers Trust Company Lines: 11 Message-ID: <30C8875A.826@BankersTrust.com> NNTP-Posting-Host: nycsew0068.btco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0b3 (WinNT; I) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Is there a generally accepted model on how CGI programs on an external Web server (sitting on the external segment of a firewall) can securely access internal databases thro' the firewall? I've dug thro' the mailing list archives and haven't seen any resolution on this. Thanks, -Guru gurus@btco.com From firewalls-owner Fri Dec 8 12:24:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA02082 for firewalls-outgoing; Fri, 8 Dec 1995 11:45:38 -0800 (PST) Received: from telxon.mis.telxon.com (TELXON.MIS.TELXON.COM [149.23.2.4]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA02077 for ; Fri, 8 Dec 1995 11:45:34 -0800 (PST) Received: from sbridg.mis.telxon.com by telxon.mis.telxon.com (5.61/3.1.090690-Telxon Corporation) id AA04124; Fri, 8 Dec 95 14:45:12 -0500 Message-Id: <9512081945.AA04124@telxon.mis.telxon.com> From: jwojn@telxon.mis.telxon.com (Wojno, Jim) Date: Fri, 08 Dec 1995 14:41 EST To: firewalls@greatcircle.com Subject: HP-UX Based Firewalls Sender: firewalls-owner@GreatCircle.COM Precedence: bulk To All: My company is considering an HP-UX machine to act as our new firewall, due to the high performance of these units. Does anyone have any information regarding commercial firewalls for the HP-UX environment? There are three that I know of: Eagle's Raptor (which I understand is very good), ASG (Atlantic Systems Group) and Morning Star. I haven't heard very much about the other two, and have never seen them mentioned on this list (although I am fairly new to this list, so I may have missed it :-) Does anyone have any first hand knowledge of these firewalls, and if so, how do you feel about them. Any info you can provide would be appreciated. If you would like to contact me directly, my email address is jwojn@telxon.com. Thanks in advance, Jim Wojno Systems Administrator Telxon Corporation P.S. I apologize if this is posted twice. We are having some trouble with our mail setup today. From firewalls-owner Fri Dec 8 12:28:04 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA01816 for firewalls-outgoing; Fri, 8 Dec 1995 11:30:33 -0800 (PST) Received: from cpcsat.sfos.ro (cpcsat.sfos.ro [193.226.31.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA01779 for ; Fri, 8 Dec 1995 11:29:11 -0800 (PST) Received: from cpcpub.sfos.ro by cpcsat.sfos.ro with SMTP (5.65/1.2-eef) id AA10097; Fri, 8 Dec 95 18:43:07 +0100 Received: (from uucp@localhost) by cpcpub.sfos.ro (8.7.1/8.6.12) with UUCP id TAA09732 for firewalls@GreatCircle.com; Fri, 8 Dec 1995 19:48:11 +0200 Received: (from tufa@localhost) by lclsv.sfos.ro (8.6.9/8.6.9) id VAA00366; Thu, 7 Dec 1995 21:02:49 +0200 Date: Thu, 7 Dec 1995 21:02:48 +0200 From: Tufa Lucian Reply-To: Tufa Lucian Subject: The local-net doesn't work... 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 somebody tell me why my local linux network doesn't work anymore . I verified the know stuff , but the local net is still inoperable . I say : Welcome to any new ideea or some help !!! Thanks... Tufa Lucian sysadmin lclsv.sfos.ro (40)-042-322028 From firewalls-owner Fri Dec 8 12:54:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA00603 for firewalls-outgoing; Fri, 8 Dec 1995 10:36:52 -0800 (PST) Received: from ion3.ionet.net (ion3.ionet.net [204.96.200.8]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA00598 for ; Fri, 8 Dec 1995 10:36:49 -0800 (PST) Received: from tektr.ionet.net (osip65.ionet.net [204.96.200.115]) by ion3.ionet.net (8.6.12/8.6.12) with SMTP id MAA21872 for ; Fri, 8 Dec 1995 12:37:42 -0600 Date: Fri, 8 Dec 1995 12:37:42 -0600 Message-Id: <199512081837.MAA21872@ion3.ionet.net> X-Sender: tektr@ionet.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@GreatCircle.COM From: Tim Richardson Subject: Firewall Performance Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hello All, I have some basic questions as a "newbie" to firewalls. First: What are the performance issues regarding some "turn-key" solutions that reside on PC's. Can they perform both packet filtering and application proxies responsibly given a T1 connection, Web access, etc? Second: Given a short time frame to implement a firewall solution for our company, does anyone have any feedback regarding solutions such as Cybergaurd and Gauntlet. Third: Does a site necessarily need application level security? I think so, however others in our organization feel that routers offer ample security. I realize that relying on solutions such as these present additional problems, ie. control over what is originally implemented, security access, and so on. Can anyone shed some light on these topics. Thanks in advance Tim From firewalls-owner Fri Dec 8 13:05:53 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA02511 for firewalls-outgoing; Fri, 8 Dec 1995 12:08:45 -0800 (PST) Received: from gatekeeper.Bridge.COM (gatekeeper.bridge.com [167.76.159.11]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA02505 for ; Fri, 8 Dec 1995 12:08:41 -0800 (PST) Received: (from mailproxy@localhost) by gatekeeper.Bridge.COM (8.6.12/8.6.9) id OAA17585; Fri, 8 Dec 1995 14:03:48 -0600 Received: from ignatz.bridge.com(167.76.24.6) by gatekeeper.Bridge.COM via smap (V1.0mjr) id sma017578; Fri Dec 8 14:03:39 1995 Received: from ernie.bridge.com by ignatz.bridge.com with SMTP id AA19056 (5.67b/IDA-1.5); Fri, 8 Dec 1995 14:15:28 -0600 Date: Fri, 8 Dec 1995 14:15:28 -0600 From: Ken Hardy Message-Id: <199512082015.AA19056@ignatz.bridge.com> To: gavin@theboard.reednews.co.uk Subject: Re: Pre-forking Proxies? Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Gavin Aiken wrote: >Does anyone know of any other proxy code that can run in a pre-forking >configuration, similar to NCSA's httpd? Or does anyone have a view I'm eager to see whether some really useful replies come from your query. There is the CERN proxy, which will run in standalone mode, obviating the need to re-read the config file for each connection. It does not, however, pre-fork; it forks on demand. It's also, I understand, a piece of dead code; works well now, but no new development is anticipated. (Correction invited.) As far as this group is concerned, it also raises the issue of size & complexity vs. security, and administration of a separate security configuration outside of netperm-table. There are, I believe, other proxies out there (harvest, &c.?), but am unfamiliar with them. -- KH From firewalls-owner Fri Dec 8 13:32:10 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA03884 for firewalls-outgoing; Fri, 8 Dec 1995 12:56:55 -0800 (PST) Received: from bwh.harvard.edu (bwh.harvard.edu [134.174.81.34]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA03879 for ; Fri, 8 Dec 1995 12:56:51 -0800 (PST) Received: from calloway.bwh.harvard.edu (calloway.bwh.harvard.edu [134.174.81.46]) by bwh.harvard.edu (8.6.9/8.6.9) with ESMTP id PAA01389; Fri, 8 Dec 1995 15:57:29 -0500 From: Adam Shostack X-Organization: Brigham & Womens Hospital, A Teaching Affiliate of Harvard Medical School Received: by calloway.bwh.harvard.edu (8.6.9) id PAA05574; Fri, 8 Dec 1995 15:56:24 -0500 Message-Id: <199512082056.PAA05574@calloway.bwh.harvard.edu> Subject: Re: HP-UX Based Firewalls To: jwojn@telxon.mis.telxon.com (Wojno, Jim) Date: Fri, 8 Dec 1995 15:56:24 -0500 (EST) Cc: firewalls@GreatCircle.COM In-Reply-To: <9512081945.AA04124@telxon.mis.telxon.com> from "Wojno, Jim" at Dec 8, 95 02:41:00 pm X-PGP: 0xE794DA91 FD3C3450FEB4A0B8 18F2E72CA82D29B8 X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk When choosing a firewall platform, machine performance is often not very important. If you have a T1 line, just about anything can handle the load. If you have more connectivity, performance may be an issue. Choose a platform you are familiar with, and can work with. If HP-UX is that platform, fine. Don't go for a new environment for firewalls. Adam You wrote: | My company is considering an HP-UX machine to act as our new firewall, due | to the high performance of these units. Does anyone have any information | regarding commercial firewalls for the HP-UX environment? There are three | that I know of: Eagle's Raptor (which I understand is very good), ASG | (Atlantic Systems Group) and Morning Star. I haven't heard very much about | the other two, and have never seen them mentioned on this list (although I | am fairly new to this list, so I may have missed it :-) -- "It is seldom that liberty of any kind is lost all at once." -Hume From firewalls-owner Fri Dec 8 13:58:09 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA04721 for firewalls-outgoing; Fri, 8 Dec 1995 13:14:09 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA04701 for ; Fri, 8 Dec 1995 13:13:52 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id PAA02541; Fri, 8 Dec 1995 15:19:36 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id PAA02537; Fri, 8 Dec 1995 15:19:36 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id PAA00236; Fri, 8 Dec 1995 15:15:24 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id PAA04470; Fri, 8 Dec 1995 15:15:24 -0600 From: Rick Smith Message-Id: <199512082115.PAA04470@shade.sctc.com> Subject: Re: Firewall Selection Criteria To: mrm@alpharel.com (Mike Murphy) Date: Fri, 8 Dec 1995 15:15:24 -0600 (CST) Cc: smith@sctc.com, firewalls@GreatCircle.com In-Reply-To: <199512080134.RAA24993@visalia.optigfx.com> from "Mike Murphy" at Dec 7, 95 05:34:24 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > >> >Mike Murphy says: > > > >> Yes. I have a simple idea of how to warrant a firewall. > >> > >> "If the system(s) protected by this firewall is(are) entered > >> in an unauthorized manner through the firewall, then Blort > >> Industries will pay arbitrated damages in an amount not to > >> exceed $1.25e6 US. Determination of unauthorized entry will > >> be verified by court appointed arbitrator." I ask: > I spend a great deal of time analyzing the alleged unauthorized > entry. For money. On an incident by incident basis. I hire experts. > It's expensive. It's a last resort. I weigh facts and observations... > oh, it was a rhetorical question, sorry. :-) No, it wasn't a rhetorical question. If this problem can be solved to everyones' satisfaction you might just see it happen. The point was that you need to analyze the evidence. Is there going to be enough evidence to decide one way or another? Will the evidence be in a form that you can trust? If crucial evidence is "missing" how does that affect the decision? By making this an "arbitration" issue it perhaps lies more on the technical merit of the evidence than on legal fine points. Which means that we can probably discuss it here without being too bogus. > I didn't hear much response about product liability insurance. It all turns on the same issue: how do you determine fault? External attack via a firewall is only one threat against information resources. How do we tell if an attack succeeded because of a firewall failure or because of some other organizational security failure? Insurance is rarely unconditional, and usually hinges on some amount of responsible behavior by the insured. For big bucks the insurance company is certainly going to make sure the insured followed the rules. Rick. smith@sctc.com secure computing corporation From firewalls-owner Fri Dec 8 14:26:46 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA07015 for firewalls-outgoing; Fri, 8 Dec 1995 14:08:02 -0800 (PST) Received: from gauntlet-1.trusted.com (gauntlet-1.trusted.com [204.254.155.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA07010 for ; Fri, 8 Dec 1995 14:07:55 -0800 (PST) Received: by gauntlet-1.trusted.com; id RAA10399; Fri, 8 Dec 1995 17:13:28 -0500 Received: from hilo.trusted.com(10.0.1.126) by gauntlet-1.trusted.com via smap (T3.1) id xma010395; Fri, 8 Dec 95 17:13:23 -0500 Received: from vanidor.trusted.com by hilo.trusted.com with SMTP (1.37.109.4/16.2) id AA22121; Fri, 8 Dec 95 17:07:49 -0500 Message-Id: <9512082207.AA22121@hilo.trusted.com> X-Sender: avolio@hilo.trusted.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Dec 1995 17:07:06 -0500 To: jwojn@telxon.mis.telxon.com (Wojno, Jim), firewalls@GreatCircle.COM From: Frederick M Avolio Subject: Re: HP-UX Based Firewalls Sender: firewalls-owner@GreatCircle.COM Precedence: bulk The Gauntlet Internet Firewall is available for HP-UX. Mail to gauntlet-info@tis.com will get information, and mail to gauntlet-sales@tis.com will get a person. Fred At 02:41 PM 12/8/95 EST, Wojno, Jim wrote: >My company is considering an HP-UX machine to act as our new firewall, due >to the high performance of these units. Does anyone have any information >regarding commercial firewalls for the HP-UX environment? There are three > ... --- TIS's Trusted Network Systems division has moved. New e-mail is avolio@trusted.com (although avolio@tis.com will work) New voice number is 301-527-9500 x115 New fax number is 301-527-0482 New address is TIS, 2277 Research Boulevard, Rockville, MD 20850 From firewalls-owner Fri Dec 8 15:00:46 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA06753 for firewalls-outgoing; Fri, 8 Dec 1995 14:03:09 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA06745 for ; Fri, 8 Dec 1995 14:03:04 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id QAA03294; Fri, 8 Dec 1995 16:08:20 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id QAA03290; Fri, 8 Dec 1995 16:08:20 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id QAA00758; Fri, 8 Dec 1995 16:04:06 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id QAA05941; Fri, 8 Dec 1995 16:04:07 -0600 Date: Fri, 8 Dec 1995 16:04:07 -0600 From: Rick Smith Message-Id: <199512082204.QAA05941@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, un04!mthomps1%manukau.govt.nz@iconz.co.nz Subject: Re: NT Security and NTFS -Reply Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Matthew Thompson says: >If you can physically access the box and reboot it you can do anything >you want with Unix, Netware or anything else. B level security and Type >Enforcement don't help against binary disk editors. Encryption of disk >data would. Not even encryption atop Type Enforcement and sprinkled with A1 pixie dust will save you from a determined person with ongoing physical access. It prevents disclosure if your site is physically attacked once and the equipment is carried off by bandits. If that's the only physical access threat that worries you, then encryption is fine. It might not be adequate to protect stuff in a public lab, though. Rick. smith@sctc.com secure computing corporation From firewalls-owner Fri Dec 8 15:24:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA10124 for firewalls-outgoing; Fri, 8 Dec 1995 15:01:54 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.235.77]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id PAA10119 for ; Fri, 8 Dec 1995 15:01:49 -0800 (PST) Received: from pferguso-pc.cisco.com (c1robo8.cisco.com [171.68.13.18]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id PAA27365; Fri, 8 Dec 1995 15:02:03 -0800 Message-Id: <199512082302.PAA27365@lint.cisco.com> X-Sender: pferguso@lint.cisco.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Dec 1995 18:02:22 -0500 To: "Frank K. Senter" From: Paul Ferguson Subject: Re: TokenRing Firewalls Cc: dnewman@mcgraw-hill.com, firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Yes, I was speaking to the issue of MAC layer filtering. That was my point, as I presumed the discussion was concerning MAC layer filtering as opposed to TCP/IP firewalls. - paul At 08:34 AM 12/8/95 -0600, Frank K. Senter wrote: >Wait a minute! You are mixing apples and oranges, and while that's a >good basis for fruit salad, it shouldn't be used to say that token ring >topology poses problems for firewalls. Source route bridging is TR's MAC >layer way of getting communications across the various segments that make >up a site's LAN. I think we are talking about TCP/IP firewalls, which >would mean that any partitioning of a LAN (or separating a LAN from your >Internet providor) calls for distinct IP networks on each side of the >firewall, and hence some routing function. SRB is terminated at the >router. You won't see an RI field that shows packet A coming from >"segment 001 via bridge 1, 002 via *router* XXX.XXX.XXX.XXX". > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso@cisco.com c i s c o S y s t e m s From firewalls-owner Fri Dec 8 16:54:28 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA14478 for firewalls-outgoing; Fri, 8 Dec 1995 16:41:17 -0800 (PST) Received: from bastion.fulcrum.com.au (fulcrum.com.au [203.2.211.248]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id QAA14401 for ; Fri, 8 Dec 1995 16:40:49 -0800 (PST) Received: (from uucp@localhost) by bastion.fulcrum.com.au (8.6.11/8.6.11) with UUCP id LAA25041 for firewalls@greatcircle.com; Sat, 9 Dec 1995 11:41:35 +1100 Received: from pegasus (pegasus [203.2.211.1]) by fulcrum.com.au (8.6.11/8.6.11) with ESMTP id LAA03819 for ; Sat, 9 Dec 1995 11:36:19 +1100 From: Rik Harris Received: (rik@localhost) by pegasus (8.6.11/8.6.11) id LAA03878; Sat, 9 Dec 1995 11:36:18 +1100 Date: Sat, 9 Dec 1995 11:36:18 +1100 Message-Id: <199512090036.LAA03878@pegasus> To: firewalls@greatcircle.com Subject: Re: is a second filter router worthwhile? Newsgroups: fulcrum.lists.firewalls References: <9511300754.AA18106@citecub.citec.qld.gov.au> <817781151.2199@nntphost.fulcrum.com.au> Reply-To: rik.harris@fulcrum.com.au Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In firewalls vanuskae@halsp.hitachi.com (Eric Vanuska) writes: >Thanks for your reply. Your comment below is at the heart of what I'm asking. >> Deleted cogent remarks about the importance of the last line >> of defense and having your filters closest to where they are needed. >> >> You allow TCP only to ports > 1023 to everyone. Unfortunately this >> is the biggest security hole. It is needed for FTP to work. It also >> means you have to be very careful about what servers are running >> on port > 1023 on the inside, or close your eyes and hope noone >> gets that close. >> >Agreed, with vanilla TCP the ftp server creates a new TCP connection back to the >client on destination port > 1023 and return port 21. With TIS the initial TCP >destination port is bumped up to some higher number (> 30,000). >I fear even this is too great of a risk!! I worry about PC's, Mac's, WIndows NT, >WIn 95, OS/2, Novell/IP, etc? We harden the hosts we control, but there are too >many hosts that we don't control. But once a hacker has a foot-hold, everything >can be lost. Soooooooo, is the hole I've described easily exploited? And what can >be done about this? Please don't tell me disable FTP. :) [as always, these solutions may help some people, and be completely useless for others] Several people have suggested PASV ftp, and this is a very valid solution in some cases. Comment #1: One problem with using PASV ftp on the external connection is that there are a small number of ftp servers which sit behind firewalls themselves and don't allow the client->server DATA connection to be opened. In some cases, you can ignore these sites, but in our case, they were some of the most used sites (Sun U.S., and Sun Aust.) Problem #1: Ftp is an inherently insecure and difficult to firewall protocol. Allowing standard ftp through your firewall involves opening up a large hole to let the connections come back in, and using PASV ftp has problems with client availability and and server reachability. Potential Solution #1: One possibility is to do something like this: Client <----> Int. <----> Bastion <----> Ext. <----> Internet Router Router PASV ftp PORT ftp ftp -CTRL----------ftp-> ftp proxy -CTRL-----------ftp-> ftp server client -DATA----------ftp-> <-retport------DATA- where the return DATA connection on the external ftp (retport) goes through a hole in your external router (say 43000-44000). Having a hole like this is a risk, but it's exposing 1000 ports on your bastion host only. If you open up a hole like this on your internal router, you're exposing 1000 x n ports, where n is the number of internal machines enabled for ftp. Given that you have one, relatively secure, host in danger (let's face it, it is a good idea to treat the bastion host as a sacrifical host anyway) you can be quite sure that there are no other services listening on ports 43000-44000. Compared to "let everything above 1023 through", this method reduces total exposure from 64512 x n ports to 1000 ports. To implement this, you need to modify the ftp proxy to send PORT commands in the 43000-44000 range, which is about 5 lines of code. I recommend choosing the port randomly from that range. You also need to have an ftp proxy which will accept PASV connection and make PORT connections. I'm not sure if any of the various versions of the FWTK ftp proxy do this. Problem #2: There are a lot of ftp clients which don't do PASV. This method requires that a PASV-cabable ftp client is used. In some cases this is fine, but in others it is not. It can be difficult to replace the ftp client on some machines, particularly DOS/Windows/Mac type machines. Potential Solution #2: In some cases, it may be appropriate to mandate that all ftp must be done via an http proxy. Your users would use Netscape (or whatever), with the ftp_proxy set to http://firewall:p/. The http proxy would do all the ftping for you, and communications with the client would go through the internal filter on a single, client-initiated TCP connection to port p. Client <----> Int. <----> Bastion <----> Ext. <----> Internet Router Router proxy HHTP PORT ftp ftp <-------------http-> http proxy -CTRL-----------ftp-> ftp server client <-retport------DATA- The http proxy would be modified in the same way as the ftp proxy to select retport in the 43000-44000 range. Again, about 5 lines of code, and choose the port randomly. Contradiction #1 ?: It may seem strange that I consider this a potential solution, where before I said that changing everyone's ftp clients to ones that support PASV was a problem. The reason for this is that I have found a general willingness for an organisation to roll out a Netscape install for every system. It is much more difficult to standardise an existing base of ftp software. People tend to install web browsers on their systems by themselves (in organisations where this is possible), and if all you have to say to them is "configure Netscape this way, and ftp will work for you" instead of "you have to give up that ftp software that you've been happily using internally for 5 years" you have a much easier task. Treat it like a benefit "Oh, and when you install Netscape, you can do everything from the one program... it slices, it dice... oops sorry" :-) Potential Solution #3: Socks is another likely solution. I dismissed it very early in it's life because it required modification to client software, which was almost impossible for DOS/Windows/Mac/etc clients. Since then, socks-cabable clients have become _much_ more common and it is becoming a viable solution for large organisations. Try ftp://ftp.nec.com for socks. have fun, rik. -- The Fulcrum Consulting Group (note phone number change) o ------------------------------------------------------------------------------ Rik Harris - rik.harris@fulcrum.com.au +61 3 9621-2100 (BH) /\ 12th Floor, 10-16 Queen St. Melbourne VIC 3000. +61 3 9621-2724 (Fax) From firewalls-owner Fri Dec 8 19:56:09 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id TAA20704 for firewalls-outgoing; Fri, 8 Dec 1995 19:24:04 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id TAA20698 for ; Fri, 8 Dec 1995 19:23:59 -0800 (PST) Message-Id: <199512090323.TAA20698@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA240629494; Sat, 9 Dec 1995 14:24:54 +1100 From: Darren Reed Subject: Re: TokenRing Firewalls To: Paul@cheops.anu.edu.au, Ferguson@cheops.anu.edu.au, Date: Sat, 9 Dec 1995 14:24:54 +1100 (EDT) Cc: Firewalls@GreatCircle.COM (Firewalls Mailing List) In-Reply-To: from "Frank K. Senter" at Dec 8, 95 08:34:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I wrote: > The link layer (Token Ring/Ethernet/PPP) should not make any >difference to > your firewall. If you go for the proxy firewall, it makes 0 difference, > only some packet filter types might have trouble if they've only been > implemented to support Ethernet frames. ie it won't be of concern to your > ciscos if you include them as part of your firewall. Paul Ferguson wrote: > However, if its *routed* and not bridged, it becomes much more of a > palatable exercise to filter traffic. I would also suggest that access > control at layer 3 is much less CPU intensive than at layer 2. To > generically state that 'it won't be of concern' is the Wrong Thing. I was refering to it (link layer) not making any difference to ip access list writing, extended or not, for firewalling. You should still be dropping all incoming packets, except for a few you want to allow through. I was assuming that the cisco would enable you to write such access lists without needing to worry, too much, about whether routing or bridging is done...(assuming you're not bridging your token ring to the internet O:) darren From firewalls-owner Sat Dec 9 06:24:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA00649 for firewalls-outgoing; Sat, 9 Dec 1995 06:07:54 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA00644 for ; Sat, 9 Dec 1995 06:07:50 -0800 (PST) Date: Sat, 9 Dec 1995 9:08:47 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951209090847.2021b89e@hobbes.orl.mmc.com> Subject: NT Bulkheads Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >While I personally wouldn't advise using it for about five years, someone >has put a firewall on NT. Perhaps, even if it is not perfect (i.e., bug >free), it could be effective and cheap enough to serve as a "bulkhead" >within an internal network. Perhaps others might wish to comment on this >news item. >OTC 12/07 1308 NETWORK-1 DEMONSTRATES FIREWALL/PLUS ON WINDOWS/NT Oh I would not have any problem with it, one of the nice things about the Intel platform is that a appication can take complete control of the system and mask the OS out entirely - have rason to believe that some customers said "can it run on an NT platform" and the vendor said "Suuuurrrrreee". For example my freeware antivirus stuff runs under Windoze 95. It also runs under Novell NOS. I see no reason why it would not run under NT, since the operating system exists only to execute some files. Since Network-1 already has an attractive firewall product (and Bill Hancock is one of only two people I know who can speak digitally) that runs under MS-DOS, I see no reason it could not do the same thing under NT if someone wanted to go to that expense. The question to ask is "does the firewall do anything differently/more than the MS-DOS product ?" I suspect that for performance reasons, *any* Intel- based firewall product that can keep up with T-1 or better is doing everything important from the port and BIOS level. No operating system required. Warmly, Padgett From firewalls-owner Sat Dec 9 06:54:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA00826 for firewalls-outgoing; Sat, 9 Dec 1995 06:25:29 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA00821 for ; Sat, 9 Dec 1995 06:25:24 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id JAA14651; Sat, 9 Dec 1995 09:25:48 -0500 Date: Sat, 9 Dec 1995 09:25:48 -0500 Message-Id: <199512091425.JAA14651@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Rick Smith , peter@nmti.com (Peter da Silva) From: Anton J Aylward Subject: Re: chroot/setuid vs type enforcement Cc: smith@sctc.com, anton@the-wire.com, firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 13:06 6/12/95 -0600, Rick Smith wrote: >I wrote: > >> > To be honest, aren't we really discussing a security model for Unix >> > that's been extracted in retrospect? > >Peter Da Silva replied: > >> Nope. It was pretty obvious to me at UCB in 1980. I believe that CSRG >> understood it too... after all I was just a freshman, they were grad >> students. > >[ SNIP ] > >One reason chroot() is clearly *not* mandatory access control is >because the networking code isn't the only place that chroot() style >protection is broken. Maybe we have it backward. Sometimes, I notice, Anglo Saxon culture in general and North American English in particular leads the user to consider the verb not the noun. That is a thing is what you say it is, not what it does. (E.g. the way the Russians viewed Regan's talking about peace while moving troops up.) In Days of Yore, chroot() had nothing to do with security. What it did have to do with was emulating a new file system root for playing around with different distribution configurations. Back then no-one said anything about it being involved with "Security", so no one figured it in when evaluating it for security. Kind of like a specification; the spec says this doesn't access that chunk of data therefore we don't need to validate how it maintains the integrity of it. Except a decade later someone IS using it in that way, a way it was never intended for. So I think we have to be casreful about who we blame. I still think the Berkeley crowd were culpable for coming up with "sockets" rather than a "/dev/tcp/ports/smtp" style model. They had a demo of "how to do it" in front of them. Yes, they were presured and all that, yes they weren't given a requirement which addressed security, yes they weren't geniuses of the order of Richie, Thompson, Kernighan and Pike. To my mind, the security SHOULD be embeded in the kernel not in the application code. Embedding it in the "/dev/tcp/ports/smtp" level driver would do that. So would TE.. I favour the former ebcuase it is the familiar structure, and as an ex-kernel hacker I have a good idea of how little that would take to acheive, especially with STREAMS. This is not to dispute or despise the need for mathematic underpinning of the implementation. I think it was Nohr who said "There's nothing so practical as a useful theory". While quoting: Norbet Weiner, "Render unto Man the things that are Man's and unto the Computer the things that are the Computer's" - GOd and Golem Inc. Which, in this context, measn that enforcing security is the job of the computer, that is the kernel, not the man, the application programmer. If we can all agree on that, I think this thread is now mature enough that we can move on to the flames and ad-hominem attacks. ;-) ;-) ;-) /anton --- Anton J Aylward The Strahn and Strachan Group Inc Information Security Consultants Voice: (416) 494-8661 Fax: (416) 494-8803 From firewalls-owner Sat Dec 9 09:54:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA03473 for firewalls-outgoing; Sat, 9 Dec 1995 09:31:51 -0800 (PST) Received: from netcom10.netcom.com (netcom10.netcom.com [192.100.81.120]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA03467 for ; Sat, 9 Dec 1995 09:31:48 -0800 (PST) Received: from dale.netcom.com by netcom10.netcom.com (8.6.12/Netcom) id JAA03590; Sat, 9 Dec 1995 09:30:58 -0800 Date: Sat, 9 Dec 1995 09:30:58 -0800 Message-Id: <199512091730.JAA03590@netcom10.netcom.com> X-Sender: dalel@netcom.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@greatcircle.com From: Dale Lancaster Subject: Re: Windows NT Firewall Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 09:39 AM 12/8/95 est, you wrote: >While I personally wouldn't advise using it for about five years, someone >has put a firewall on NT. Perhaps, even if it is not perfect (i.e., bug >free), it could be effective and cheap enough to serve as a "bulkhead" >within an internal network. Perhaps others might wish to comment on this >news item. > I would be interested in the factual minuses of running a firewall on NT as well. Does anyone have specifics on the drawbacks of NT vs. Unix other than NT is viewed by most Unix supporters as not being a real OS? I'm not a NT detractor or supporter, just a knowledgeable Unix guy looking to understand NT. >SAN FRANCISCO, Dec. 7 /PRNewswire/ -- Network-1 Software and Technology >Inc. this week became the first network firewall development company to >show a firewall running on a Windows/NT(TM) platform. Network-1 >demonstrated a working prototype version of its popular FireWall/Plus(TM) ^^^^^^^^^^^^^^ a GUI?? >The Windows/NT prototype of FireWall/Plus was demonstrated at DECUS '95/San . . . >Network-1 plans to ship the completed versions of FireWall/Plus for >Windows/NT and Windows-95 by spring. Is this vendor-speak for "we are the first to annouce vapor-ware firewalls for NT" ? just curious :-) dale ========================================================================== Dale Lancaster Dallas, Texas 214-423-6212 ========================================================================== From firewalls-owner Sat Dec 9 10:24:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA03911 for firewalls-outgoing; Sat, 9 Dec 1995 10:08:13 -0800 (PST) Received: from hnc.hnc.com (hnc.hnc.com [206.79.10.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id KAA03905 for ; Sat, 9 Dec 1995 10:08:08 -0800 (PST) Received: (from uucp@localhost) by hnc.hnc.com (8.7.1/8.7.1) id KAA11779 for ; Sat, 9 Dec 1995 10:23:13 -0800 (PST) Received: from serval.hnc.com(206.79.54.2) by hnc.hnc.com via smap (V1.3) id sma011777; Sat Dec 9 10:22:44 1995 Received: from spike.hnc.com (spike.hnc.com [191.9.201.52]) by serval.hnc.com (8.7.1/8.7.1) with ESMTP id KAA09868 for ; Sat, 9 Dec 1995 10:13:07 -0800 (PST) Received: from fred.hnc.com (fred.hnc.com [191.9.204.7]) by spike.hnc.com (8.7.1/8.7.1) with SMTP id KAA24256 for ; Sat, 9 Dec 1995 10:11:47 -0800 (PST) Message-Id: <199512091811.KAA24256@spike.hnc.com> Received: from pcdwl.hnc.com by fred.hnc.com with SMTP (1.38.193.4/16.2) id AA11273; Sat, 9 Dec 1995 10:14:41 -0800 X-Sender: dwl@spike X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 09 Dec 1995 10:11:49 -0800 To: firewalls@greatcircle.com From: David Loysen Subject: Re: NT Bulkheads Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 09:08 AM 12/9/95 -0500, you wrote: >>While I personally wouldn't advise using it for about five years, someone >>has put a firewall on NT. Perhaps, even if it is not perfect (i.e., bug >>free), it could be effective and cheap enough to serve as a "bulkhead" >>within an internal network. Perhaps others might wish to comment on this >>news item. >>OTC 12/07 1308 NETWORK-1 DEMONSTRATES FIREWALL/PLUS ON WINDOWS/NT > >Oh I would not have any problem with it, one of the nice things about the >Intel platform is that a appication can take complete control of the >system and mask the OS out entirely - have rason to believe that some >customers said "can it run on an NT platform" and the vendor said >"Suuuurrrrreee". > >For example my freeware antivirus stuff runs under Windoze 95. It also runs >under Novell NOS. I see no reason why it would not run under NT, since >the operating system exists only to execute some files. > >Since Network-1 already has an attractive firewall product (and Bill Hancock >is one of only two people I know who can speak digitally) that runs under >MS-DOS, I see no reason it could not do the same thing under NT if someone >wanted to go to that expense. > >The question to ask is "does the firewall do anything differently/more than >the MS-DOS product ?" I suspect that for performance reasons, *any* Intel- >based firewall product that can keep up with T-1 or better is doing everything >important from the port and BIOS level. No operating system required. > > Warmly, > Padgett > > It is probably more likely that I don't understand your answer than that you are wrong.... But, isn't one of the features of NT that only the OS is allowed to talk to the hardware and all applications talk only to the OS? I'm not sure how a firewall software could get around this, I do know that DOS based virus scanners will not run in a dos window under NT (I've tried it). If I'm way off base on this please let me know, I are a newbie and don't know plenty. "When the going gets weird, the weird turn pro." Hunter S. Thompson, The Curse of Lono. dwl@hnc.com HNC Software Inc. David Loysen 5930 Cornerstone Ct. West (619) 546-8877 x245 San Diego, CA 92121-3728 fax (619) 452-6524 From firewalls-owner Sat Dec 9 12:24:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA06075 for firewalls-outgoing; Sat, 9 Dec 1995 12:07:25 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id MAA06066 for ; Sat, 9 Dec 1995 12:07:18 -0800 (PST) Received: from rcooper.the-wire.com (rcooper.the-wire.com [198.53.159.74]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id PAA23628; Sat, 9 Dec 1995 15:07:42 -0500 Received: by rcooper.the-wire.com with Microsoft Mail id <01BAC647.F9EC4AA0@rcooper.the-wire.com>; Sat, 9 Dec 1995 15:06:54 -0500 Message-ID: <01BAC647.F9EC4AA0@rcooper.the-wire.com> From: Russ Cooper To: "'David Loysen'" , "firewalls@GreatCircle.COM" Subject: RE: NT Bulkheads Date: Sat, 9 Dec 1995 15:06:52 -0500 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk David Loysen asks ..."But, isn't one of the features of NT that only the OS is allowed to talk to the hardware and all applications talk only to the OS? I'm not sure how a firewall software could get around this"... There are two ways in NT for hardware to be manipulated. Either the NT Kernel (base OS) can issue a call to the Hardware Abstraction Layer (HAL), or, an Executive service known as the I/O manager can send a directive to a device driver, which in turn can talk directly to the hardware. Since Networking services are done within the scope of the I/O Manager, any attempt to control NT's networking would have to be done either completely as a device driver, or as a process running in Kernel mode. The only way for a firewall implementation on NT to "take complete control of the system and mask the OS out entirely", to quote Padgett, would be to have it implemented entirely as a device driver. In this case, its would not be possible to dynamically modify parameters, or to make much use out of graphical controls, as was indicated in the press release. So, presumably the Firewall-1 implementation is operating as a Kernel mode process interacting with both the Networking subsystem (within the I/O Manager) and the Security Reference Monitor (the sole Kernel mode process responsible for enforcing security, validating access to objects, checking user privileges, and generating audit messages). Its possible, of course, that they have replaced the Networking subsystem with one of their own over which they could exert more control. Since the Security Reference Monitor is used to determine access to all objects, it would need to be cracked in order to access whatever process Firewall-1 is running in Kernel mode. Cheers, Russ Cooper, Senior Internet Integration Engineer SHL/Computer Innovations (now an MCI company) RCooper@the-wire.com or RWCooper@shl.com "where do you wanna go to get the money to go to where you wanna go today" From firewalls-owner Sat Dec 9 13:24:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA06895 for firewalls-outgoing; Sat, 9 Dec 1995 13:00:28 -0800 (PST) Received: from wabash.iac.net (wabash.iac.net [198.180.60.138]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA06889 for ; Sat, 9 Dec 1995 13:00:24 -0800 (PST) Received: by wabash.iac.net id QAA18383; Sat, 9 Dec 1995 16:01:16 -0500 Date: Sat, 9 Dec 1995 16:01:15 -0500 (EST) From: Carl Jolley To: Tim Richardson cc: firewalls@GreatCircle.COM Subject: Re: Firewall Performance In-Reply-To: <199512081837.MAA21872@ion3.ionet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Fri, 8 Dec 1995, Tim Richardson wrote: > Hello All, > > I have some basic questions as a "newbie" to firewalls. > > First: What are the performance issues regarding some "turn-key" solutions > that reside on PC's. Can they perform both packet filtering and application > proxies responsibly given a T1 connection, Web access, etc? > > Second: Given a short time frame to implement a firewall solution for our > company, does anyone have any feedback regarding solutions such as > Cybergaurd and Gauntlet. > Well, as is said, "time is money". So if your time is short, throw some money at your problem and implement the Gauntlet. The standard platform for the Gauntlet is am Intel Pentium running BSDI. I consider that a PC, I'm not certain if you would, too. The Gauntlet box can handle a T1 with application proxies, Web access, etc. however I would rrecommend a separate screening router sitting between the Gauntlet and the Internet connection. > Third: Does a site necessarily need application level security? I think so, > however others in our organization feel that routers offer ample security. > I'm not sure why people think that routers provide security. The basic purpose of a router is to move packets between network interfaces. The basic purpose of a security device like a firewall is to, on the other hand, prevent the flow of packets between network interfaces. To me, they appear different, in fact, almost directly opposite. A router performs a set of valuable data communications functions and when the business needs of you or your organization requires some or all of those functions, you should use a router. A firewall performs a set of valuable data security and data access control functions and when the business needs of your or your organization requires some or all of those functions, you should use a firewall. The Swiss Army methodology has its place when considering knives. IMO, it is not a appropriate way to design and implement a network. > I realize that relying on solutions such as these present additional > problems, ie. control over what is originally implemented, security access, > and so on. Can anyone shed some light on these topics. > In the case of the Gauntlet which is built with the "crystal box" approach, (e.g. the customer gets _all_ of the source code), I believe control over what is originally implemented _is_ in the hands of the customer. Also since it is also based on the philosophy that the only things that are permitted are those that have been specifically authorized, what is originally implemented seems pretty safe to me since in the case of the Gauntlet that is exactly nothing. Absolutely no information will flow throught the Gauntlet unless you tell it to allow specific information through. I'm not sure what you mean by your reference to security access. > Thanks in advance > Tim > You're welcome. **** cjolley@iac.net **** All opinions are my own and not necessarily those of my employer **** From firewalls-owner Sat Dec 9 13:54:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA07313 for firewalls-outgoing; Sat, 9 Dec 1995 13:24:51 -0800 (PST) Received: from wabash.iac.net (wabash.iac.net [198.180.60.138]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA07307 for ; Sat, 9 Dec 1995 13:24:45 -0800 (PST) Received: by wabash.iac.net id QAA18803; Sat, 9 Dec 1995 16:25:41 -0500 Date: Sat, 9 Dec 1995 16:25:39 -0500 (EST) From: Carl Jolley To: Rick Smith cc: Mike Murphy , smith@sctc.com, firewalls@GreatCircle.COM Subject: Re: Firewall Selection Criteria In-Reply-To: <199512082115.PAA04470@shade.sctc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Fri, 8 Dec 1995, Rick Smith wrote: > > >> >Mike Murphy says: > > > > > >> Yes. I have a simple idea of how to warrant a firewall. > > >> > > >> "If the system(s) protected by this firewall is(are) entered > > >> in an unauthorized manner through the firewall, then Blort > > >> Industries will pay arbitrated damages in an amount not to > > >> exceed $1.25e6 US. Determination of unauthorized entry will > > >> be verified by court appointed arbitrator." > > I ask: > > > I spend a great deal of time analyzing the alleged unauthorized > > entry. For money. On an incident by incident basis. I hire experts. > > It's expensive. It's a last resort. I weigh facts and observations... > > oh, it was a rhetorical question, sorry. :-) > > No, it wasn't a rhetorical question. If this problem can be solved to > everyones' satisfaction you might just see it happen. > > The point was that you need to analyze the evidence. Is there going to > be enough evidence to decide one way or another? Will the evidence be > in a form that you can trust? If crucial evidence is "missing" how > does that affect the decision? > > By making this an "arbitration" issue it perhaps lies more on the > technical merit of the evidence than on legal fine points. Which means > that we can probably discuss it here without being too bogus. > > > I didn't hear much response about product liability insurance. > > It all turns on the same issue: how do you determine fault? External > attack via a firewall is only one threat against information > resources. How do we tell if an attack succeeded because of a firewall > failure or because of some other organizational security failure? > Insurance is rarely unconditional, and usually hinges on some amount > of responsible behavior by the insured. For big bucks the insurance > company is certainly going to make sure the insured followed the > rules. > Trying to get a blanket gaurantee or warranty from a firewall vendor sounds akin to trying to get a warrenty from a hardware manufacturer that the hammer you bought from them won't allow you to hit your thumb. About the most you might achieve from such an exercise is a promise that you won't hit your thumb accidentally if the tool is used as intended by the manufacturer. If you do hit your thumb accidently, they'll only have to say that it was intended only to be used to hit nails. > Rick. > smith@sctc.com secure computing corporation > **** cjolley@iac.net **** All opinions are my own and not necessarily those of my employer **** From firewalls-owner Sat Dec 9 17:54:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id RAA11971 for firewalls-outgoing; Sat, 9 Dec 1995 17:47:02 -0800 (PST) Received: from colt.milepost.com (colt.milepost.com [164.57.50.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id RAA11963 for ; Sat, 9 Dec 1995 17:46:57 -0800 (PST) Received: (from phil@localhost) by colt.milepost.com (8.6.12/8.6.9) id TAA00468; Sat, 9 Dec 1995 19:47:29 -0600 From: Phil Howard Message-Id: <199512100147.TAA00468@colt.milepost.com> Subject: Re: Windows NT Firewall To: dalel@netcom.com (Dale Lancaster) Date: Sat, 9 Dec 1995 19:47:28 -0600 (CST) Cc: firewalls@GreatCircle.COM In-Reply-To: <199512091730.JAA03590@netcom10.netcom.com> from "Dale Lancaster" at Dec 9, 95 09:30:58 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > I would be interested in the factual minuses of running a firewall on NT as > well. Does anyone have specifics on the drawbacks of NT vs. Unix other than > NT is viewed by most Unix supporters as not being a real OS? I'm not a NT > detractor or supporter, just a knowledgeable Unix guy looking to understand NT. I'm a UNIX supporter that is not trying to claim NT is not a real OS. It could be very real. I just don't know much about it. But that is the first reason I won't use it... that I don't know much about it. The second reason is that I have not yet found anyone else that knows anywhere near as much about NT as I know about UNIX. UNIX in it's many flavors varies from dark gray boxes to crystal clear boxes. NT, on the other hand, is a black box. It's just too hard to tell exactly what it is doing. It may be doing something, but I can't tell if it is doing what I want it to do. The configuration is a bit difficult, too, since it is always based on GUI. GUI (and even command in many cases) types of configuration frequently leave out subtleties that the traditional editing of files can offer. For instance, the ability to control the exact order and timing of things. Thus, my third reason for not using NT. > >Network-1 plans to ship the completed versions of FireWall/Plus for > >Windows/NT and Windows-95 by spring. > > Is this vendor-speak for "we are the first to annouce vapor-ware firewalls > for NT" ? It means they just sent the order to the head hunters to find some people with 5+ years of NT experience to bring on board as temporary contractors. > ========================================================================== > Dale Lancaster > Dallas, Texas > 214-423-6212 > ========================================================================== ========================================================================== Phil Howard Dallas, Texas 214-(access denied) ========================================================================== From firewalls-owner Sat Dec 9 18:24:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id RAA12156 for firewalls-outgoing; Sat, 9 Dec 1995 17:56:14 -0800 (PST) Received: from switchblade.iwi.com (switchblade.iwi.com [137.39.156.214]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id RAA12151 for ; Sat, 9 Dec 1995 17:56:09 -0800 (PST) Received: (from mjr@localhost) by switchblade.iwi.com (8.6.9/8.6.9) id UAA27499; Sat, 9 Dec 1995 20:57:36 -0500 From: "Marcus J. Ranum" Message-Id: <199512100157.UAA27499@switchblade.iwi.com> Subject: NT firewalls (specifically Firewall/Plus) To: firewalls@greatcircle.com Date: Sat, 9 Dec 1995 20:57:36 -0500 (EST) Cc: mjr@switchblade.iwi.com (Marcus J. Ranum) Reply-To: mjr@iwi.com Organization: Information Warehouse! Inc, Baltimore, MD URL: mjr's web page Phone: 410-889-8569 Coredump: Infocalypse Now!!! X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >While I personally wouldn't advise using it for about five years, someone >has put a firewall on NT. Perhaps, even if it is not perfect (i.e., bug >free), it could be effective and cheap enough to serve as a "bulkhead" >within an internal network. Perhaps others might wish to comment on this >news item. >OTC 12/07 1308 NETWORK-1 DEMONSTRATES FIREWALL/PLUS ON WINDOWS/NT Aaaah, good old operating systems bigotry! How it narrows the focus and how pleasantly it clouds the mind! I've done extensive testing of a Firewall/Plus system on its original DOS platform, and I know something about how it works. Do you? When holding a product up for ridicule, you can do a better job of it if you actually know something about how it works. :) Firewall/Plus doesn't have an IP address; it operates like a bridge. I believe that what Network-1 did for the NT port is ported their packet switching engine, and hooked it in between the IP stack and the network interface class drivers. I'm not an NT guru; they are, so I'm not 100% sure of the implementation details. But I can tell you that I spent a merry day flinging packets at a Firewall/Plus trying to get it to be visible to IP on the network - with no success. My understanding is that the only major change between the DOS and NT versions is that the NT version has the packet switching engine separated out from the user interface driver, to take advantage of multitasking. My take on Firewall/Plus is that it's on a par with a SunScreen, but a whole lot cheaper and it works on commodity hardware. It doesn't do IP/IP encryption but I'm sure it will anon. As far as operating systems bigotry goes -- NT has, in my experience, proven quite robust in the face of adversity. From a security perspective, attempting to break into it, I am much more impressed with it than I am with UNIX. From a robustness perspective, I have few complaints; it is on a par with most commercial versions of UNIX. Once you get past implementation details, operating systems simply aren't interesting. What is interesting is what they let you *accomplish*. mjr. From firewalls-owner Sat Dec 9 18:54:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id SAA13498 for firewalls-outgoing; Sat, 9 Dec 1995 18:53:03 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id SAA13492 for ; Sat, 9 Dec 1995 18:52:59 -0800 (PST) Received: from rcooper.the-wire.com (rcooper.the-wire.com [198.53.159.74]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id VAA29749 for ; Sat, 9 Dec 1995 21:53:35 -0500 Received: by rcooper.the-wire.com with Microsoft Mail id <01BAC680.B411F820@rcooper.the-wire.com>; Sat, 9 Dec 1995 21:52:58 -0500 Message-ID: <01BAC680.B411F820@rcooper.the-wire.com> From: Russ Cooper To: "'Firewalls'" Subject: FW: Windows NT Firewall Date: Sat, 9 Dec 1995 21:52:57 -0500 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Phil Howard recently said ..."The second reason is that I have not yet found anyone else that knows anywhere near as much about NT as I know about UNIX." I'm sure there are folks out there who know far more about their 1972 Pinto than I know about my 1994 Nissan, that sure as heck doesn't make the Pinto better for me to drive to work in today. You're just more familiar with your tools, and can therefore be more productive in your environment. Your lack of awareness to the suite of tools available for NT doesn't make it a bad choice. "UNIX in it's many flavors varies from dark gray boxes to crystal clear boxes. NT, on the other hand, is a black box. It's just too hard to tell exactly what it is doing. It may be doing something, but I can't tell if it is doing what I want it to do." Fact is, with the symbolic libraries for NT, it is far easier than you imply to follow program execution through all of its iterations. How do you think people write device drivers and service processes? "The configuration is a bit difficult, too, since it is always based on GUI. GUI (and even command in many cases) types of configuration frequently leave out subtleties that the traditional editing of files can offer. For instance, the ability to control the exact order and timing of things. Thus, my third reason for not using NT." The timing and order of execution of "things" can easily be specified in an NT application, service, or device driver. It simply has a performance impact that is unnecessary in most GUI applications. "It means they just sent the order to the head hunters to find some people with 5+ years of NT experience to bring on board as temporary contractors." I guess the point here is that there aren't very many people around with 5+ years of NT experience. The fact is, in my mind, that 5+ years experience with NT is unnecessary anyway. Reality is, in today's software environment, not very much is around for that long anyway. There's far more Unix-like functionality in the coding of NT apps and services than some Unix programmers realize. Is this all just a matter that Unix Experts feel threatened by a new wave of NT experts? From firewalls-owner Sun Dec 10 04:24:24 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id EAA23070 for firewalls-outgoing; Sun, 10 Dec 1995 04:03:42 -0800 (PST) Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.6]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id EAA23064 for ; Sun, 10 Dec 1995 04:03:36 -0800 (PST) Received: from smtpgty.saicuk.co.uk by flow.pipex.net with SMTP (PP); Sun, 10 Dec 1995 12:01:18 +0000 Received: by smtpgty.saicuk.co.uk with Microsoft Mail id <30CACA62@smtpgty.saicuk.co.uk>; Sun, 10 Dec 95 11:54:10 GMT From: "Johnson-Bryden, Ian" To: "'firewalls@greatcircle.com'" Subject: Re: Windows NT Firewall Date: Sun, 10 Dec 95 11:37:00 GMT Message-ID: <30CACA62@smtpgty.saicuk.co.uk> X-Mailer: Microsoft Mail V3.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >Phil wrote >I'm a UNIX supporter that is not trying to claim NT is not a real OS. >It could be very real. I just don't know much about it. But that is >the first reason I won't use it... that I don't know much about it. >The second reason is that I have not yet found anyone else that knows >anywhere near as much about NT as I know about UNIX. >UNIX in it's many flavors varies from dark gray boxes to crystal clear >boxes. NT, on the other hand, is a black box. It's just too hard to >tell exactly what it is doing. It may be doing something, but I can't >tell if it is doing what I want it to do. >The configuration is a bit difficult, too, since it is always based >on GUI. GUI (and even command in many cases) types of configuration >frequently leave out subtleties that the traditional editing of files >can offer. For instance, the ability to control the exact order and >timing of things. Thus, my third reason for not using NT. In one sense the OS used for a firewall shouldnt really matter because the only applications it should be running are firewall applications. Therefore the arguments for standardising across an enterprise dont really apply to the firewall. The only argument which might hold up is if you have only technical skills in one particular OS and have to spend time learning about the new one introduced by the firewall. Some of the NT enthusiasts dont yet know what NT is, much less its suitability for a firewall system. Equally, a number expect to mount a range of non-firewall applications on the firewall machine to save money. Some anti Bill people claim that a lack of source code availability at the user site is the reason not to use NT. Thats a not strong point because some excellent trusted products are available only in runtime. The *big* difference is that they come from reputable vendors with strong specialist experience who are prepared to submit to independent evaluation and use UNIX source in building their trusted OS products and providing a tested packaged solution. One problem facing vendors of that sort is that they cant get the same co-operation on products like NT. Lack of access introduces 2 risk groups. One is that you have to build on foundations which could be the 1cm you can see or go right down to bedrock. The way NT was presented under TCSEC suggests theres not much below 1cm. The other risk is that you probably never have any idea of what development is taking place in the product and therefore you risk losing your development over night because the OS vendor says "sorry it was all a joke, we wont vend that OS anymore". Ian J-B From firewalls-owner Sun Dec 10 06:24:24 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA24081 for firewalls-outgoing; Sun, 10 Dec 1995 06:15:48 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA24067 for ; Sun, 10 Dec 1995 06:15:41 -0800 (PST) Received: from anton.the-wire.com (anton.the-wire.com [198.53.192.186]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id JAA07937; Sun, 10 Dec 1995 09:14:53 -0500 Date: Sun, 10 Dec 1995 09:14:53 -0500 Message-Id: <199512101414.JAA07937@psyche.the-wire.com> X-Sender: anton@the-wire.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Anthony.W.Youngman" From: Anton J Aylward Subject: chroot vs TE (Was Re: William of Occam) Cc: firewalls@greatcircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 15:21 7/12/95 GMT, "Anthony.W.Youngman" wrote: > > >William of Occam (or Ockham, in Yorkshire, or Surrey) was a medieval >philosopher - presumed dates 1285-1349 - who is attributed with saying >"Occam's razor", "Entia non sunt multiplicanda praeter necessitatem", or >"Entities are not to be multiplied beyond necessity". > >The modern English version I am familiar with is: >Make things as simple as possible - but no simpler. > No I don't believe it is off topic. Peter da Silva recently pointed out that the original UNIX security model was quite comprehensive (the file system model) and was simple enough to be implemented in 64K for code+data. Again, by one of Pike's laws, it was fast because it was small. By the standardz of any operating system around at the time, UNIX was extremely small and simple, becuase non of the internal mechanisms was any more complicated than it needed to be. I recall one of Richie's papers discussing the idea of using linear search of small internal tables becuase the code was small, simple and anything more complicated would not have shown benefit. OK, since then we've built huge great baroque cathederals with all their complicated filligrie and buteresses. And if adding ACL and TE isn't buteressing up things which were addded later that were not part of the original design ("sockets") I dodn't know what is. But do we remove the ugo/rwx bits when we add ACL or TE? On the systems such as HP that I've had to battle with this, NO! So the kernel has to have some way of resolving these two approaches. This adds code and complexity. Even if you have a good theoretical model of how the resolution is to be done, its still new code. It can still produce all manner of 'hidden gotchas'. Now I have nothing against ACL or TE. What I'm against is adding complexity - and in this case using both the traditional UNIX security model and one of these is a very blatent case of multiplying prime entities beyond necessity. It is "beyond necessity" because the UNIX filesystem and ugo/rwx model COULD have been used. If we were dealing with a new "Very Mammoth System" which was following some POSIX-like API but was based from the begining on TE, that's another matter. To mix in some more metaphors, it seems to take a certain kind of genius to have the insight to make things simple in the way Einstein proposed, and that Richie et al did for UNIX in the first place. What I see now reminds me of the sitation in Chalker's "River of the Dancing Gods" series. Or if you like, the Ptolemaic model of the universe at the time of Tycho Brahe - spheres upon spheres upon epicyles upon more epicylces to correct the disparities. The difference is that the Ptolemaic model was wrong in that it was theoretically inadequate. The UNIX model isn't wrong, it isn't even inadequate; its lack of application to the networking interface was inadequate. While Rick Smith has defended the TE model most righteously - and I agree with him about the righteousness of the approach et al - I've not seen anyone scream down that "/dev/tcp/ports/smtp" would be a fitting approach. (OK, I'm putting up a straw-man.) What also springs to mind is a difference in cultural context. I'm reminded of Marvin Harris's defence of the Indian "Sacred Cows", showing how they are positive ecological contributions in context, and that Western Dairy farming would completely devastate the ecology there. The point being that criticising the Indians for their attitude towards their cows show up OUR ignorance. (E.g in his book 'Cultural Materialism') TE, ACL and even sempahores are not part of UNIX's cultural context. (I would even go so far as to say semaphores are as pernicious as GOTO statements), the use of the file system to provide and control access to resources IS part of the cultural context. Perhaps what we need to do is revise POSIX to get rid of sockets and tli and replace it with this file system model. And if you meet Sysiphus on his way down, say hello from me. /anton ---------------------------------------------------------------------------- ------------------------------------------------------------------------------ Anton J Aylward | Security is not something that comes in a self-contained The Strahn and Strachan Group Inc | box. It is an attibute of how you do business, and as such Information Security Consultants | needs to be managed carefully. Voice: (416) 494-8661 Fax: (416) 494-8803 | - Karen Goertzel, Wang Federal Inc. From firewalls-owner Sun Dec 10 08:24:24 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA25264 for firewalls-outgoing; Sun, 10 Dec 1995 08:21:32 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA25259 for ; Sun, 10 Dec 1995 08:21:28 -0800 (PST) Date: Sun, 10 Dec 1995 11:22:32 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951210112232.2021f367@hobbes.orl.mmc.com> Subject: re: Windows NT Firewall Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >I would be interested in the factual minuses of running a firewall on NT as >well. Does anyone have specifics on the drawbacks of NT vs. Unix other than >NT is viewed by most Unix supporters as not being a real OS? I'm not a NT >detractor or supporter, just a knowledgeable Unix guy looking to understand NT. Well since the memory requirement for NT is about what I would want a good 'wall to have and I have easy access to ring 0, if NT came for free on the system, I would not be adverse to using it to load the firewall. >Is this vendor-speak for "we are the first to annouce vapor-ware firewalls >for NT" ? Suspect is more a matter of figuring out how to port the GUI to NT and make sure that every trace of NT is out of the memory path before starting the firewall. The "real" program will probably be exactly the same as used with Plain Old Dos (POD). Look at how Netware loads. Hardest part will be bringing NT back & you probably have to stop the 'wall to do so. The fact is that a firewall is essentially a serial real-time process. Packet comes in. Decisions are made. (Maybe) packet goes out. The hard part is the one that says "decisions" but many simply do an interpretive table lookup on the ACL. Proxying is a bit harder. Full application filtering is *much* harder and is why few even attempt it (though many claim to). Even so, the better ones find time to paint part of a screen to give a picture of what is going on (is probably the most difficult piece to do fast, expect a lot is maintained in the video memory just like a 3270 terminal used to do). Warmly, Padgett From firewalls-owner Sun Dec 10 08:54:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA25512 for firewalls-outgoing; Sun, 10 Dec 1995 08:40:46 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA25507 for ; Sun, 10 Dec 1995 08:40:42 -0800 (PST) Date: Sun, 10 Dec 1995 11:41:47 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951210114147.2021f367@hobbes.orl.mmc.com> Subject: re: Windows NT Firewall Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Russ rites: >Since Networking services are done within the scope of the I/O Manager, any >attempt to control NT's networking would have to be done either completely >as a device driver, or as a process running in Kernel mode. The only way >for a firewall implementation on NT to "take complete control of the system >and mask the OS out entirely", to quote Padgett, would be to have it >implemented entirely as a device driver. In this case, its would not be >possible to dynamically modify parameters, or to make much use out of >graphical controls, as was indicated in the press release. Ever look at the DS2MOV component in my DISKSECURE program ? It is a "device driver" that takes complete control of the system while running (and tweaks a few things that M$ said could not be done). Wrote it three years ago and while the tuning indicator in Windows 95 complains, it works just fine. Can even be used on a Novell Netware server but I don't know why you would bother - DOS goes away when you execute SERVER. I agree that if you want to take advantage of NT services, you must follow this process but if you do not use the OS at all or can directly access cerain modules, then "no problemo". Indicators that this is done would be a restriction on disk type, network cards supported, video cards supported, or printers supported. But the bottom line is that am Intel platform with BIOS is a fully functional computer in its own right. True, the first thing you do for a flat memory model and real high speed work is to dump the BIOS, go into "protected" mode, and use direct port access (why you have to specify the card port addresses/IRQs for network cards and they have to be informed what the selection is). You do not need an OS for anything except pre-initialization and to load your program. But why ask me ? Ask the vendors. Warmly, Padgett From firewalls-owner Sun Dec 10 09:24:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA25584 for firewalls-outgoing; Sun, 10 Dec 1995 08:52:39 -0800 (PST) Received: from colt.milepost.com (colt.milepost.com [164.57.50.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA25579 for ; Sun, 10 Dec 1995 08:52:32 -0800 (PST) Received: (from phil@localhost) by colt.milepost.com (8.6.12/8.6.9) id KAA00700; Sun, 10 Dec 1995 10:53:20 -0600 From: Phil Howard Message-Id: <199512101653.KAA00700@colt.milepost.com> Subject: Re: NT firewalls (specifically Firewall/Plus) To: mjr@iwi.com Date: Sun, 10 Dec 1995 10:53:20 -0600 (CST) Cc: firewalls@GreatCircle.COM In-Reply-To: <199512100157.UAA27499@switchblade.iwi.com> from "Marcus J. Ranum" at Dec 9, 95 08:57:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > Aaaah, good old operating systems bigotry! How it narrows > the focus and how pleasantly it clouds the mind! I've done extensive > testing of a Firewall/Plus system on its original DOS platform, and > I know something about how it works. Do you? When holding a product > up for ridicule, you can do a better job of it if you actually know > something about how it works. :) Don't you just love those debates? I'd probably trust a firewall on DOS (especially DOS 3.3) more than on any other system. That's because the firewall itself has to do all the calls. There are not hidden network holes if the underlying system doesn't know what a network is. My security concerns have to address all parts of the system. Looking at Firewall/Plus on system X vs. Firewall/Plus on system Y ends up being a comparison of system X to system Y. > As far as operating systems bigotry goes -- NT has, in > my experience, proven quite robust in the face of adversity. From > a security perspective, attempting to break into it, I am much > more impressed with it than I am with UNIX. From a robustness > perspective, I have few complaints; it is on a par with most > commercial versions of UNIX. UNIX is only my 4th OS that I professionally work on (numerous more that I played with). NT could well be my 5th and I look forward to it. But there are some realities to consider even before we consider the systems in particular. The new system is most certainly going to have fewer gurus around. That's both good and bad. It's bad that you might not find one to hire. It's good that there aren't as many that know the attack points. Even today, whole new holes are found in many systems, including UNIX and the servers that usually run on it. If I can find a hole on NT, that will not mean it's a bad system. No system can be perfect, and UNIX is far from perfect. But I do want a system that can be dealt with. NT is becoming more and more of that system, and for many it already satisfies their needs. > Once you get past implementation details, operating > systems simply aren't interesting. What is interesting is what > they let you *accomplish*. That probably depends on the person. I find operating systems interesting themselves. Applications are boring. But I'm a theory nut making a living in a practical world. I've never seen a "perfect" OS, and I doubt if I ever do. Just like no security system is 100%, either; we just see that as the goal and try to push as close as possible. From firewalls-owner Sun Dec 10 14:24:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA02027 for firewalls-outgoing; Sun, 10 Dec 1995 14:19:06 -0800 (PST) Received: from beast.brainlink.com (beast.brainlink.com [206.127.58.17]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA02022 for ; Sun, 10 Dec 1995 14:19:02 -0800 (PST) Received: (from rootmail@localhost) by beast.brainlink.com (8.6.12/8.6.12) id RAA13622; Sun, 10 Dec 1995 17:22:22 -0500 Date: Sun, 10 Dec 1995 17:22:21 -0500 (EST) From: root To: firewalls@GreatCircle.COM Subject: SSL'd WU-FTPd In-Reply-To: <199512080527.VAA05092@eagle.wd.cubic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Q1) Anyone know where I could get my hands on an SSL patch for WU-ftpd?? I've seen the FTPd that comes with SSL, but WU have so many nice features... Q2) Anyone have leads on a cheap S/Key calculator?? laptops are cumbersome and paper printouts a major risk... Thanks. ========= << raj >> == http://www.brainlink.com/~frostbit/ ============== frostbit@brainlink.com SYSADMIN: BrainLINK System (718) 805-8868 // http://www.brainlink.com GCS d++ H-- s+:+ !g p2 !au a- w+ v-* C++++ US++++ L++ P+++ E- N+ W--- M-- po Y+ t-- 5+++ j++ tv b+++ e++ u+ h++ f+ r++ n+ y+ ============================================================================ From firewalls-owner Sun Dec 10 14:54:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA01904 for firewalls-outgoing; Sun, 10 Dec 1995 14:08:06 -0800 (PST) Received: from ctasim.com (ctasim.com [206.6.123.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA01894 for ; Sun, 10 Dec 1995 14:08:03 -0800 (PST) Received: by deepthought.ctasim.com (931110.SGI/920502.SGI.AUTO) for @ctasim.com:firewalls@GreatCircle.COM id AA03696; Sun, 10 Dec 95 15:12:39 -0700 Date: Sun, 10 Dec 95 15:12:39 -0700 From: jon@ctasim.com (Jon Doran) Message-Id: <9512102212.AA03696@deepthought.ctasim.com> To: firewalls@GreatCircle.COM Subject: modems and accessing the internal network Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I would like to hear everyone's comments on modem pool placement. Brent and Elizabeth suggest in their book to place them on the internal network and protect them really well. Hmm, does anyone else have a problem with this? To me the purpose of the firewall is to protect the internal network by providing a clear separation between the internal and external networks. I really don't like the idea of allowing an end-run around the Bastion hosts. I also don't care if J. Random Hacker dials in or telnets in. Authentication makes me feel better, and I'd like the same treatment for dial-in users as for telnet users. I'd like dial-in users to be authenticated via authsrv and allowed to connect to the internal network only. J Random Hacker then needs to compromise the authentication daemon, which would let him/her ruin all of your days as surely as if he/she were logged in locally. I haven't given serious thought to this, but something like a dial-in account (equivalent to dial-in password) with telnet as a shell (on a machine without the outbound proxy, so packet filters could kill outbound tn traffic) might work. The caller would need to authenticate before going anywhere (I hope). Can anything like this be done fairly easily, without compromising security? If not, what does everyone else do? Jon Doran jon@ctasim.com ----------------------------------------------------------------- Jon Doran CTA Simulation Systems, LLC 7315 E. Orchard Rd, Suite 100 Greenwood Village, CO 80111 (303) 889-1270 jon@ctasim.com From firewalls-owner Sun Dec 10 16:24:24 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA05338 for firewalls-outgoing; Sun, 10 Dec 1995 16:17:16 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.235.77]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id QAA05333 for ; Sun, 10 Dec 1995 16:17:12 -0800 (PST) Received: from pferguso-pc.cisco.com (c1robo14.cisco.com [171.68.13.24]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id QAA28077; Sun, 10 Dec 1995 16:17:53 -0800 Message-Id: <199512110017.QAA28077@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Dec 1995 19:18:11 -0500 To: jon@ctasim.com (Jon Doran) From: Paul Ferguson Subject: Re: modems and accessing the internal network Cc: firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 03:12 PM 12/10/95 -0700, Jon Doran wrote: >I would like to hear everyone's comments on modem pool placement. Brent >and Elizabeth suggest in their book to place them on the internal network >and protect them really well. > >Hmm, does anyone else have a problem with this? To me the purpose of the >firewall is to protect the internal network by providing a clear separation >between the internal and external networks. I really don't like the idea >of allowing an end-run around the Bastion hosts. > As long as you authenticate dial-in access, then its not an end-run. :-) Its certainly more palatable, in my opinion, than any placment on an external network, where the possibility exists of someone compromising the external network and sniffing packets for passwords. - paul -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso@cisco.com c i s c o S y s t e m s From firewalls-owner Sun Dec 10 16:54:24 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA05593 for firewalls-outgoing; Sun, 10 Dec 1995 16:39:22 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id QAA05588 for ; Sun, 10 Dec 1995 16:39:18 -0800 (PST) Date: Sun, 10 Dec 1995 19:40:22 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951210194022.2021a7b4@hobbes.orl.mmc.com> Subject: Simplicity & "Whut we got" programming (was chroot vs TE) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Anton (wally?) rote: >Peter da Silva recently pointed out that the original UNIX security model was >quite comprehensive (the file system model) and was simple enough >to be implemented in 64K for code+data. Again, by one of Pike's laws, >it was fast because it was small. By the standardz of any operating system >around at the time, UNIX was extremely small and simple, becuase non of the >internal mechanisms was any more complicated than it needed to be. Unfortunately, many lemmings lacking any other criteria seem to expect to buy software by the byte - have had People In The Know tell me that my anti-virus software is too small to sell (of course, I *don't* sell it, it is FreeWare unless someone wants customization). The fact that maxterms & minterms plus quite a bit of blood-sweating was required to pare the intercept down to under 300 bytes (decimal not hex - I figure my age in hex 8*) & no performance impact is lost on most. At the same time, I do not blame those who are constrained to larger fuctions because they are denied the joys of assembly and BIOS programming, not everyone has that kind of eccentricity (now writing a program to create a Christmas Card in ASCII with the coder limited to 64 bytes max, THAT is insanity (but the math said it was possible & who am I to argue - question: does anyone else create a math model of functions to determine exactly how many bytes the program should take ?). The problem is the libraries and the compilers required to support them, not so much the programs themselves. Turbo C takes over 20k to say "Hello World" which coulld be done in 20(h) bytes. I put up with Turbo C because it is needed to interface with the Waterloo libraries. This makes 1k files bloat to 30k. When C++ is loaded from CD-Rom (around here...somewhere) it takes over 70 Mb but is needed to interface with the FTP ONNET SDK (plug). Problem is that when you use libraries (and programmers *must* to meet delivery dates) you incur inefficiencies - but they usually work as long as you stay within the design envelope. Belm wit that is that the compiler rarely does or enforces range checking (ADA is supposed to but who uses ADA ?) >To mix in some more metaphors, it seems to take a certain kind of genius >to have the insight to make things simple in the way Einstein proposed, and >that Richie et al did for UNIX in the first place. The problems with each is that people down the line have insisted on taking each out of context. For example, Einstein said "to an observer, this will appear..." and the great unwashed took this to mean "it is". Similarly, UNIX is a ->great<- development system/language but a *terrible* user system. >What I see now reminds me of the sitation in Chalker's "River of the >Dancing Gods" series. How so ? *Everything* is covered by the books (do have to wonder about anyone who's favourite characters seem to be blind, pregnant, obese women. Ferry boats now...) to the extent that if you try to violate the lawz *they will not let you* (sorry to be imprecise - cannot get to that bookcase right now - way is blocked by a MAC SE/30, a PS2-55, a tandem cat carrier, and three Zenith 248-kit 5s. Is a four-line PBX in there somewhere also). We could only wish that C were so protective. >TE, ACL and even sempahores are not part of UNIX's cultural context. >(I would even go so far as to say semaphores are as pernicious as > GOTO statements), the use of the file system to provide and control >access to resources IS part of the cultural context. True, thing is TCP/IP *is* part of the UNIX culture to the extent that during the late-'80s when just about everyone was proclaiming its death that was about the only repository. Perhaps if ISO/OSI had succeeded, we would not be here today. It didn't and we is. Warmly, Padgett From firewalls-owner Sun Dec 10 17:54:24 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id RAA08261 for firewalls-outgoing; Sun, 10 Dec 1995 17:47:01 -0800 (PST) Received: from mail.Clark.Net (mail.clark.net [168.143.0.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id RAA08253 for ; Sun, 10 Dec 1995 17:46:55 -0800 (PST) Received: from clark.net (proberts@clark.net [168.143.0.7]) by mail.Clark.Net (8.7.3/8.6.5) with ESMTP id UAA12350 for ; Sun, 10 Dec 1995 20:47:55 -0500 (EST) Received: (from proberts@localhost) by clark.net (8.7.1/8.7.1) id UAA20429; Sun, 10 Dec 1995 20:47:50 -0500 (EST) Date: Sun, 10 Dec 1995 20:47:47 -0500 (EST) From: "Paul D. Robertson" To: firewalls@greatcircle.com Subject: Re: modems and accessing the internal network In-Reply-To: <199512110017.QAA28077@lint.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Sun, 10 Dec 1995, Paul Ferguson wrote: > At 03:12 PM 12/10/95 -0700, Jon Doran wrote: > > >I would like to hear everyone's comments on modem pool placement. Brent > >and Elizabeth suggest in their book to place them on the internal network > >and protect them really well. > > > >Hmm, does anyone else have a problem with this? To me the purpose of the > >firewall is to protect the internal network by providing a clear separation > >between the internal and external networks. I really don't like the idea > >of allowing an end-run around the Bastion hosts. > > > > > As long as you authenticate dial-in access, then its not an end-run. :-) > This depends on what protocols you allow. If you allow dial-in IP, and the other end is on an externally connected network, then it most certainly is an end-run. > Its certainly more palatable, in my opinion, than any placment on an > external network, where the possibility exists of someone compromising > the external network and sniffing packets for passwords. > I'd rather see hubs on the outside, though I'm not sure if I'll not argue for yet another DMZ/proxy for dial-up IP Paul. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts@clark.net which may have no basis whatsoever in fact." PSB#9280 From firewalls-owner Sun Dec 10 19:24:24 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id TAA10513 for firewalls-outgoing; Sun, 10 Dec 1995 19:10:59 -0800 (PST) Received: from ctasim.com (ctasim.com [206.6.123.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id TAA10402 for ; Sun, 10 Dec 1995 19:10:40 -0800 (PST) Received: by deepthought.ctasim.com (931110.SGI/920502.SGI.AUTO) for @ctasim.com:proberts@clark.net id AA04881; Sun, 10 Dec 95 20:15:09 -0700 Date: Sun, 10 Dec 95 20:15:09 -0700 From: jon@ctasim.com (Jon Doran) Message-Id: <9512110315.AA04881@deepthought.ctasim.com> To: "Paul D. Robertson" Subject: Re: modems and accessing the internal network Cc: firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Sun Dec 10 19:23:23 1995, Paul D. Robertson wrote: > This depends on what protocols you allow. If you allow dial-in IP, and > the other end is on an externally connected network, then it most certainly > is an end-run. Thats a good one. Even if they came into our DMZ (which has static routing tables) all they need to do is run proxy servers on their machine and everyone could come on in. Of course whoever did this would be tortured severely. Jon Doran ----------------------------------------------------------------- Jon Doran CTA Simulation Systems, LLC 7315 E. Orchard Rd, Suite 100 Greenwood Village, CO 80111 (303) 889-1270 jon@ctasim.com From firewalls-owner Sun Dec 10 19:54:24 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id TAA11028 for firewalls-outgoing; Sun, 10 Dec 1995 19:33:37 -0800 (PST) Received: from scruz.net (nic.scruz.net [165.227.1.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id TAA11021 for ; Sun, 10 Dec 1995 19:33:34 -0800 (PST) Received: from histar2.ezunx.com by scruz.net (8.6.9/1.34) id TAA04887; Sun, 10 Dec 1995 19:34:36 -0800 Date: Sun, 10 Dec 95 19:33:47 PDT From: Rich Subject: RE: modems and accessing the internal network To: Jon Doran , firewalls@greatcircle.com X-Mailer: Chameleon V0.05, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I personally consider modems to be in hostile territory and therefore go on the outside of the firewall. then, if compromised, they have another level to get through. Even if authorized, and they somehow get through both the modem and the firewall, at least I have audit trails from the firewall, sicne I audit everyone/everything, trusted or not. Modems are too easily attacked, protected or not, and if the connection is on the outside, then all the better. rich -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ** Remember -- Life is NOT a dress rehearsal! (nor is it a small furry animal with funny feet and floppy ears...) From firewalls-owner Sun Dec 10 20:28:35 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA12315 for firewalls-outgoing; Sun, 10 Dec 1995 20:10:39 -0800 (PST) Received: from mail.Clark.Net (mail.clark.net [168.143.0.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id UAA12290 for ; Sun, 10 Dec 1995 20:10:33 -0800 (PST) Received: from clark.net (proberts@clark.net [168.143.0.7]) by mail.Clark.Net (8.7.3/8.6.5) with ESMTP id XAA00449; Sun, 10 Dec 1995 23:11:38 -0500 (EST) Received: (from proberts@localhost) by clark.net (8.7.1/8.7.1) id XAA23246; Sun, 10 Dec 1995 23:11:31 -0500 (EST) Date: Sun, 10 Dec 1995 23:11:27 -0500 (EST) From: "Paul D. Robertson" To: Jon Doran cc: firewalls@GreatCircle.COM Subject: Re: modems and accessing the internal network In-Reply-To: <9512110315.AA04881@deepthought.ctasim.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Sun, 10 Dec 1995, Jon Doran wrote: > On Sun Dec 10 19:23:23 1995, Paul D. Robertson wrote: > > This depends on what protocols you allow. If you allow dial-in IP, and > > the other end is on an externally connected network, then it most certainly > > is an end-run. > > Thats a good one. Even if they came into our DMZ (which has static routing > tables) all they need to do is run proxy servers on their machine and > everyone could come on in. > > Of course whoever did this would be tortured severely. Unfortunately, in this case, so would the security staff, I'd think, since the break-in would have happend by the time you hang the geek. I still think winsock based trojans are the future, though who knows what things like Java will bring.... paraniodly, Paul. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts@clark.net which may have no basis whatsoever in fact." PSB#9280 From firewalls-owner Sun Dec 10 21:29:40 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA14047 for firewalls-outgoing; Sun, 10 Dec 1995 20:58:41 -0800 (PST) Received: from crl.crl.com (crl.com [165.113.1.12]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id UAA14042 for ; Sun, 10 Dec 1995 20:58:37 -0800 (PST) Received: by crl.crl.com id AA20384 (5.65c/IDA-1.5); Sun, 10 Dec 1995 20:45:42 -0800 Date: Sun, 10 Dec 1995 20:45:42 -0800 (PST) From: Tim Keanini To: root Cc: firewalls@GreatCircle.COM Subject: (OTP reply)Re: SSL'd WU-FTPd In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Sun, 10 Dec 1995, root wrote: > Q2) Anyone have leads on a cheap S/Key calculator?? laptops are > cumbersome and paper printouts a major risk... Here is a brief summary of "small" computers that can be used for S/KEY: target location --- --- HP100/200LX ftp://ftp.csl.sony.co.jp/pub/HPLX/secutiry/ Psion ftp://src.doc.ic.ac.uk/computing/systems/handhelds/psion/icdoc/misc/psi-key.zip HP48S/SX/G/GX ftp://ftp.efn.org/pub/users/stevev/ ftp://ftp.box.eu.org/hp48/skey/ Newton ftp://tltsu.anu.edu.au/pub/skey. Personally, I think that the HP48G is by far the best choice if you dont already own one of the above. They can be had for ~100.00. There is place called EduCalc that has these nifty little computers and I believe the number to be 18006777001 I hope this helps because OTP is the only way to go. --blast From firewalls-owner Sun Dec 10 21:54:23 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA14565 for firewalls-outgoing; Sun, 10 Dec 1995 21:11:44 -0800 (PST) Received: from beast.brainlink.com (beast.brainlink.com [206.127.58.17]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id VAA14560 for ; Sun, 10 Dec 1995 21:11:37 -0800 (PST) Received: (from rootmail@localhost) by beast.brainlink.com (8.6.12/8.6.12) id AAA21260; Mon, 11 Dec 1995 00:15:01 -0500 Date: Mon, 11 Dec 1995 00:15:00 -0500 (EST) From: root To: firewalls@GreatCircle.COM Subject: TIS FWTK Help In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I've installed TIS FWTK and I have two problems that I haven't solved yet: 1) I need examples of the httpd-gw, plug-gw as I haven't been able to figure out how to use these effectively. Me thinks I need a brain upgrade... 2) I'm having problems with smap/smapd/sendmail. The layout is as follows: --internet--[Livingston Firewall Router]----[bastion] + +--[internal server] The bastion runs httpd, ftpd, and the proxies. I'd like to run sendmail on the internal server, with SMAP/SMAPD on the bastion. Currently, if I send mail to a user on the bastion, he gets it. If I send mail to user directly on the internal server or a user NBOT on the bastion, the mail bounes after a few days. Clues, tips, good advice cheerfully accepted. Flames directed to /dev/bill_gates ;-) ========= << raj >> == http://www.brainlink.com/~frostbit/ ============== frostbit@brainlink.com SYSADMIN: BrainLINK System (718) 805-8868 // http://www.brainlink.com GCS d++ H-- s+:+ !g p2 !au a- w+ v-* C++++ US++++ L++ P+++ E- N+ W--- M-- po Y+ t-- 5+++ j++ tv b+++ e++ u+ h++ f+ r++ n+ y+ ============================================================================ From firewalls-owner Sun Dec 10 22:24:24 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id WAA15997 for firewalls-outgoing; Sun, 10 Dec 1995 22:19:30 -0800 (PST) Received: from hosaka.smallworks.com (hosaka.SmallWorks.COM [192.207.126.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id WAA15992 for ; Sun, 10 Dec 1995 22:19:26 -0800 (PST) Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA16582; Mon, 11 Dec 1995 00:20:27 -0600 Date: Mon, 11 Dec 1995 00:20:27 -0600 From: jim@SmallWorks.COM (Jim Thompson) Message-Id: <9512110620.AA16582@hosaka.smallworks.com> To: firewalls@GreatCircle.COM, jon@ctasim.com, raf@ezunx.com Subject: RE: modems and accessing the internal network Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >Modems are too easily attacked, protected or not, and if the >connection is on the outside, then all the better. I don't get it (again?). Modems are no more easily attacked than an IP connection. Both can be very unsecure. Both can be very hard to actually sneak anything though. Jim From firewalls-owner Sun Dec 10 22:54:24 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id WAA16421 for firewalls-outgoing; Sun, 10 Dec 1995 22:27:09 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id WAA16406 for ; Sun, 10 Dec 1995 22:27:05 -0800 (PST) Received: from po.gis.prc.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA06528 for Firewalls@GreatCircle.COM; Mon, 11 Dec 95 01:28:10 -0500 Apparently-To: Message-Id: Date: 11 Dec 1995 01:37:05 U From: "Server #7000007" Subject: Undeliverable Mail X-Mailer: Mail*Link SMTP-MS 3.0.2 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Unknown Microsoft mail form. Approximate representation follows. Message: Firewalls-Digest V4 #700 Sent: Sun, Dec 10, 1995 1:08 AM To: Harris Tom On Server: PRC Bellevue NE MS Date: Mon, Dec 11, 1995 1:37 AM Reason: Could not be delivered because the destination Microsoft Mail server could not be found. From firewalls-owner Sun Dec 10 23:24:28 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id XAA18567 for firewalls-outgoing; Sun, 10 Dec 1995 23:20:59 -0800 (PST) Received: from hosaka.smallworks.com (hosaka.SmallWorks.COM [192.207.126.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id XAA18562 for ; Sun, 10 Dec 1995 23:20:52 -0800 (PST) Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA16780; Mon, 11 Dec 1995 01:21:58 -0600 Date: Mon, 11 Dec 1995 01:21:58 -0600 From: jim@SmallWorks.COM (Jim Thompson) Message-Id: <9512110721.AA16780@hosaka.smallworks.com> To: firewalls@greatcircle.com Subject: Announce: Timing cryptanalysis of RSA, DH, DSS Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >From sci.crypt.. probably only important to Firewalls where encryption is concerned. Jim From: pck@netcom.com (Paul C. Kocher) Subject: Announce: Timing cryptanalysis of RSA, DH, DSS Message-ID: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Date: Mon, 11 Dec 1995 01:33:17 GMT Lines: 67 Sender: pck@netcom20.netcom.com I've just released details of an attack many of you will find interesting since quite a few existing cryptography products and systems are potentially at risk. The general idea of the attack is that secret keys can be found by measuring the amount of time used to to process messages. The paper describes attacks against RSA, fixed- exponent Diffie-Hellman, and DSS, and the techniques can work with many other systems as well. My research on the subject is still in progress and the current paper does not include many of my findings. I will eventually publish a full paper, but am releasing a preliminary draft now to alert the community as quickly as possible. A copy of the abstract is attached at the end of this message and the full text can be downloaded in PostScript format from: ftp://ftp.cryptography.com/pub/kocher_timing_attack.ps ftp://ftp.cryptography.com/pub/kocher_timing_attack.ps.gz I've also made an HTML version which is accessible at: http://www.cryptography.com (The HTML uses subscripts and superscripts which aren't supported in older web browsers. The PostScript version is the "official" one and looks nicer.) The results have already been seen by Matt Blaze, Martin Hellman, Ron Rivest, Bruce Schneier, and many others. While the full significance of the attack is not yet known, I think everyone who has seen it considers it important (including Netscape who awarded me a $1000 bugs bounty prize). ABSTRACT. Cryptosystems often take slightly different amounts of time to process different messages. With network- based cryptosystems, cryptographic tokens, and many other applications, attackers can measure the amount of time used to complete cryptographic operations. This abstract shows that timing channels can, and often do, leak key material. The attacks are particularly alarming because they often require only known ciphertext, work even if timing measurements are somewhat inaccurate, are computationally easy, and are difficult to detect. This preliminary draft outlines attacks that can find secret exponents in Diffie- Hellman key exchange, factor RSA keys, and find DSS secret parameters. Other symmetric and asymmetric cryptographic functions are also at risk. A complete description of the attack will be presented in a full paper, to be released later. I conclude by noting that closing timing channels is often more difficult than might be expected. Cheers, Paul Kocher ********************************************************************* VERY IMPORTANT: If you send me e-mail, please understand that I probably won't have time to respond to all who write. Please keep messages SHORT and send them to pck@cryptography.com (**not** my netcom address -- misdirected messages will be ignored). PGP when used for e-mail is not vulnerable to the attack. Please state in your note whether you would like a reply. ******************************************************************** __________________________________________________________________________ Paul C. Kocher Independent cryptography/data security consultant E-mail: pck@cryptography.com (please see above before replying) ======== Xref: news2.new-york.net sci.crypt:5320 Path: news2.new-york.net!spcuna!uunet!in1.uu.net!newsfeed.internetmci.com!howland.reston.ans.net!ix.netcom.com!netnews From: jmrubin@ix.netcom.com (Joel M. Rubin) Newsgroups: sci.crypt Subject: Re: Announce: Timing cryptanalysis of RSA, DH, DSS Date: 11 Dec 1995 04:35:47 GMT Organization: Union of anti-organizationalists Lines: 11 Message-ID: <4agcf3$enr@ixnews2.ix.netcom.com> References: NNTP-Posting-Host: ix-sf17-18.ix.netcom.com X-NETCOM-Date: Sun Dec 10 8:35:47 PM PST 1995 X-Newsreader: WinVN 0.99.7 I just saw a small article with your name on page 1 of the N.Y. Times Fax 8-page Internet Edition. (Monday, December 11, 1995) They change the edition at about 10:30-11 P.M. Eastern Standard Time (0330-0400 the next GMT day) so if you read this before then, you might want to download http://nytimesfax.com/times.pdf. It is in Adobe Acrobat format. Of course, there is probably a larger article in the paper edition. ======== From: jmrubin@ix.netcom.com (Joel M. Rubin) Newsgroups: sci.crypt Subject: Re: Announce: Timing cryptanalysis of RSA, DH, DSS Date: 11 Dec 1995 04:38:58 GMT Organization: Union of anti-organizationalists Lines: 7 Message-ID: <4agcl2$enr@ixnews2.ix.netcom.com> References: NNTP-Posting-Host: ix-sf17-18.ix.netcom.com X-NETCOM-Date: Sun Dec 10 8:38:58 PM PST 1995 X-Newsreader: WinVN 0.99.7 In case you don't already know, there is an article about your work in Monday's N.Y. Times. I just read a very small version of it in http://nytimesfax.com/times.pdf. (Adobe Acrobat-format 8-page edition) The N.Y. Times Fax on the web changes edition about 10:30 or 11 P.M. New York time so if you want it, get it before then. From firewalls-owner Mon Dec 11 00:05:26 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id XAA19034 for firewalls-outgoing; Sun, 10 Dec 1995 23:28:30 -0800 (PST) Received: from mars.process.com (mars.process.com [192.42.95.144]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id LAA12230 for ; Wed, 6 Dec 1995 11:50:30 -0800 (PST) Received: from Microsoft Mail (PU Serial #1063) by mars.process.com (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm)) id AA-1995Dec06.144700.1063.274829; Wed, 06 Dec 1995 14:51:43 -0500 From: Marcus.Goncalves@mars.process.com (Goncalves, Marcus) To: Firewalls@greatcircle.com ('smtp:Firewalls@greatcircle.com') Message-ID: <1995Dec06.144700.1063.274829@mars.process.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: Process Software Corporation Date: Wed, 06 Dec 1995 14:51:43 -0500 Subject: Firewall for RAS Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I'm setting up a Windows NT RAS system for a friend and was thinking what would be the simple way to protect his internal network without going "Paramount" about it. He has a small network, 40 nodes, all running Windows NT Workstation. I'm setting up a comm. server running NT 3.51 w/ SP2 with a internal Digiboard attached to it. I'll use US Robotics modems, 28.8 and the dialback security of RAS. The idea is that, once connected to the comm. server the user would them logon to the internal network server. IS there mechanism I could use to straighten security without complicating maintenance for him (and spending much money?). Packet filtering maybe? Thanks, Marcus From firewalls-owner Mon Dec 11 00:24:24 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id XAA19419 for firewalls-outgoing; Sun, 10 Dec 1995 23:36:22 -0800 (PST) Received: from berlin.inmar-inc.com ([199.72.196.49]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA06495 for ; Fri, 8 Dec 1995 13:58:14 -0800 (PST) Received: from [200.2.10.8] by berlin.inmar-inc.com with SMTP (1.38.193.5/16.2) id AA21067; Fri, 8 Dec 1995 16:59:30 -0500 Received: from Microsoft Mail (PU Serial #1468) by mail-1.inmar-inc.com (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm)) id AA-1995Dec08.165400.1468.15836; Fri, 08 Dec 1995 16:59:58 -0500 From: dcarter@inmar-inc.com (Carter, David) To: firewalls@greatcircle.com ('firewalls'), jwojn@telxon.mis.telxon.com (Wojno, Jim) Message-Id: <1995Dec08.165400.1468.15836@mail-1.inmar-inc.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: Inmar Enterprises Inc., Winston-Salem, North Carolina, 27102 USA Date: Fri, 08 Dec 1995 16:59:58 -0500 Subject: RE: HP-UX Based Firewalls Sender: firewalls-owner@GreatCircle.COM Precedence: bulk We use Raptor's Eagle running on an HP. It seems to work pretty well for us, and the Raptor people are responsive to our requests for enhancements/fixes. We've had some issues with their documentation not being quite what we'd like, but we've been able to work through those. ---------- From: Wojno, Jim[SMTP:jwojn@telxon.mis.telxon.com] Sent: Friday, December 08, 1995 2:41 PM To: firewalls Subject: HP-UX Based Firewalls To All: My company is considering an HP-UX machine to act as our new firewall, due to the high performance of these units. Does anyone have any information regarding commercial firewalls for the HP-UX environment? There are three that I know of: Eagle's Raptor (which I understand is very good), ASG (Atlantic Systems Group) and Morning Star. I haven't heard very much about the other two, and have never seen them mentioned on this list (although I am fairly new to this list, so I may have missed it :-) Does anyone have any first hand knowledge of these firewalls, and if so, how do you feel about them. Any info you can provide would be appreciated. If you would like to contact me directly, my email address is jwojn@telxon.com. Thanks in advance, Jim Wojno Systems Administrator Telxon Corporation P.S. I apologize if this is posted twice. We are having some trouble with our mail setup today. --- D. David Carter, Director of Systems Architecture Inmar Enterprises, Inc., Winston-Salem, NC dcarter@inmar-inc.com From firewalls-owner Mon Dec 11 00:38:55 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id XAA19015 for firewalls-outgoing; Sun, 10 Dec 1995 23:27:55 -0800 (PST) Received: from TIS.COM (neptune.tis.com [192.94.214.96]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id PAA01721 for ; Tue, 5 Dec 1995 15:26:47 -0800 (PST) Received: from relay.tis.com by neptune.TIS.COM id aa29571; 5 Dec 95 18:10 EST Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (g3.0.1) id xma004318; Tue, 5 Dec 95 17:44:34 -0500 Received: from sol.tis.com by tis.com (4.1/SUN-5.64) id AA19347; Tue, 5 Dec 95 18:10:02 EST Message-Id: <9512052310.AA19347@tis.com> To: firewalls@greatcircle.com Subject: Program Announcement - ISOC 1996 Symp. Netw. & Distr. Sys. Security Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <19334.818204999.1@tis.com> Date: Tue, 05 Dec 1995 18:10:01 -0500 From: "David M. Balenson" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk ------------------------------------------------------------------------------ THE INTERNET SOCIETY 1996 SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS '96) 22-23 FEBRUARY 1996 SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA The symposium will bring together people who are building software and/or hardware to provide network and distributed system security services. The symposium is intended for those interested in the more practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than in theory. We hope to foster the exchange of technical information that will encourage and enable the Internet community to apply, deploy and advance the state of the available security technology. ------------------------------------------------------------------------------ P R E L I M I N A R Y P R O G R A M WEDNESDAY, FEBRUARY 21 6:00 P.M. - 8:00 P.M. RECEPTION - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - THURSDAY, FEBRUARY 22 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. OPENING REMARKS 9:00 A.M. SESSION 1: ELECTRONIC MAIL SECURITY Chair: Stephen T. Kent (BBN Corporation, USA) Mixing E-mail with BABEL, Gene Tsudik and Ceki Gulcu (IBM Research Division, Zurich Research Laboratory, SWITZERLAND) An Integration of PGP and MIME, Kazuhiko Yamamoto (Nara Institute of Science and Technology, JAPAN) 10:00 A.M. BREAK 10:30 A.M. SESSION 2: DISTRIBUTED OBJECT SYSTEMS Chair: Dan Nessett (Sun Microsystems, USA) A Security Framework Supporting Domain Based Access Control in Distributed Systems, Nicholas Yialelis and Morris Sloman (Imperial College, London, UNITED KINGDOM) PANEL: Scalability of Security in Distributed Object Systems Chair: Dan Nessett (Sun Microsystems, USA) Panelists: Dan Nessett (Sun Microsystems, USA), Nicholas Yialelis (Imperial College, London, UNITED KINGDOM), and Bret Hartman (Odyssey Research Associates, USA) 12:00 NOON LUNCH 1:30 P.M. SESSION 3: DISTRIBUTED SYSTEM SECURITY Chair: Michael Roe (University of Cambridge, UNITED KINGDOM) A Flexible Distributed Authorization Protocol, Jonathan Trostle (CyberSAFE, USA) and B. Clifford Neuman (Information Sciences Institute, University of Southern California, USA) Preserving Integrity in Remote File Location and Retrieval, Trent Jaeger (University of Michigan, USA) and Aviel D. Rubin (Bellcore, USA) C-HTTP - The Development of a Secure, Closed HTTP-Based Network on the Internet, Takahiro Kiuchi (University of Tokyo, JAPAN) and Shigekoto Kaihara (University of Tokyo Hospital, JAPAN) 3:00 P.M. BREAK 3:30 P.M. SESSION 4: PANEL: INTELLECTUAL PROPERTY PROTECTION Chair: Peter Neumann (SRI International, USA) Panelists: David Bernstein (Electronic Publishing Resources, USA), Russ Housley (Spyrus, USA), and Dan Boneh (Princeton University, USA) 7:00 P.M. DINNER BANQUET - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - FRIDAY, FEBRUARY 23 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. SESSION 5: NETWORK SECURITY Chair: Matt Bishop (University of California at Davis, USA) Designing an Academic Firewall: Policy, Practice and Experience with SURF, Michael B. Greenwald, Sandeep K. Singhal, Jonathan R. Stone, and David R. Cheriton (Stanford University, USA) Digital Signature Protection of the OSPF Routing Protocol, Sandra Murphy and Madelyn Badger (Trusted Information Systems, USA) A Case Study of Secure ATM Switch Booting, Shaw-Cheng Chuang and Michael Roe (University of Cambridge, UNITED KINGDOM) 10:00 A.M. BREAK 10:30 A.M. SESSION 6: KEY MANAGEMENT Chair: Burt Kaliski (RSA Laboratories, USA) SKEME: A Versatile Secure Key Exchange Mechanism for Internet, Hugo Krawczyk (IBM T.J. Watson Research Center, USA) IDUP and SPKM: Developing Public-Key-Based APIs and Mechanisms for Communication Security Services, Carlisle Adams (Bell-Northern Research, CANADA) 11:30 A.M. LUNCH 1:00 P.M. SESSION 7: ENCRYPTION Chair: Paul Lambert (Oracle, USA) An Empirical Study of Secure MPEG Video Transmissions, Iskender Agi and Li Gong (SRI International, USA) Parallelized Network Security Protocols, Erich Nahum and David J. Yates (University of Massachusetts, USA), Sean O'Malley, Hilarie Orman and Richard Schroeppel (University of Arizona, USA) A "Bump in the Stack" Encryptor for MS-DOS Systems, David A. Wagner (University of California at Berkeley, USA) and Steven M. Bellovin (AT&T Bell Laboratories, USA) 2:30 P.M. BREAK 3:00 P.M. SESSION 8: PANEL: PUBLIC-KEY INFRASTRUCTURE Chair: Warwick Ford (Bell Northern Research, CANADA) Panelists: John Wankmueller (MasterCard International, USA), Taher ElGamal (Netscape Communications, USA), and Michael Baum (VeriSign, USA). ------------------------------------------------------------------------------ GENERAL CHAIR: Jim Ellis, CERT Coordination Center PROGRAM CHAIRS: David Balenson, Trusted Information Systems B. Clifford Neuman, USC Information Sciences Institute PROGRAM COMMITTEE: Tom Berson, Anagram Laboratories Matt Bishop, University of California at Davis Doug Engert, Argonne National Laboratory Warwick Ford, Bell Northern Research (Canada) Burt Kaliski, RSA Laboratories Steve Kent, BBN Corporation Paul Lambert, Oracle John Linn, OpenVision Technologies Teresa Lunt, Advanced Research Projects Agency Dan Nessett, Sun Microsystems Hilarie Orman, University of Arizona Michael Roe, Cambridge University (UK) Rob Rosenthal, U.S. National Institute of Standards and Technology Avi Rubin, Bellcore Jeff Schiller, Massachusetts Institute of Technology Rob Shirey, BBN Corporation Doug Tygar, Carnegie Mellon University Roberto Zamparo, Telia Research (Sweden) LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Steve Welke, Institute for Defense Analyses REGISTRATIONS CHAIR: Donna Leggett, Internet Society STEERING GROUP Internet Research Task Force, Privacy and Security Research Group ------------------------------------------------------------------------------ BEAUTIFUL SAN DIEGO PRINCESS RESORT Location The Symposium venue is the San Diego Princess Resort, a tropical paradise on a forty-four acre island in Mission Bay, ten minutes from the international airport. Lush gardens landscaped with hundreds of species of tropical and subtropical plants are always ablaze with color and perfect for themed group events. Charming pathways wander among sparkling waterfalls, across quaint footbridges and sleepy lagoons filled with water lilies and waterfowl. A white sand beach curves around the island for over a mile, and the award-winning grounds encompass five swimming pools and six lighted tennis courts. Spouses and family members can catch a convenient Harbor Hopper for a quick trip to Sea World. After the Symposium, plan to spend the weekend visiting La Jolla, the world famous San Diego Zoo or Mexico, only 30 minutes by car or Trolley. Housing Information We have reserved a special block of sleeping rooms at the San Diego Princess Resort at the following rates: Lanai Patio & Garden View Rooms $ 81* Lanai Garden & Lagoon View Rooms $112 One Bedroom Suite $115 * This represents the Government Rate for San Diego. We have a limited number of rooms available at this rate. If you need a government rate, reserve your room early! You must present a valid government id upon check- in. Based on room type and space availability, these special group rates are applicable two days prior to and two days after the symposium. Current Room Tax is 10.5%. Check-in availability cannot be committed prior to 4:00 p.m. Check-out time is 12:00 noon. The San Diego Princess Resort will make every effort to accommodate any early arrivals, so make sure you give them your arrival time when you make your reservation. To make a reservation Contact the San Diego Princess Resort at 1-800-344-2626 (+1-619-274-4630 if outside the United States). To receive the special group rates, reservations must be made no later than January 20, 1996. CLIMATE February weather in San Diego is normally very pleasant. Early morning temperatures average 55 degrees while afternoon temperatures average 67 degrees. Generally, a light jacket or sweater is adequate during February; although, occasionally it rains. REGISTRATION FEES ISOC Non- Members Member Early registration (postmarked by Jan. 19) $295 $330 Late registration $365 $400 REGISTRATION INCLUDES - Attendance - Symposium Proceedings - Two luncheons - Reception - Banquet - Coffee Breaks FOR MORE INFORMATION on registration contact Donna Leggett by phone at 703-648-9888 or via e-mail to Ndss96reg@isoc.org. WEB PAGE - Additional information about the symposium and San Diego, as well as an on-line registration form, are available via the Web at: http://www.isoc.org/conferences/ndss96 ------------------------------------------------------------------------------ Internet Society Symposium on Network and Distributed System Security 22-23 February, 1996 San Diego, California, USA Registration Form --------------------------------------------------------------------------- Fill out this form and FAX it to NDSS'96 Registration (703) 648-9887, send it via electronic mail to Ndss96reg@isoc.org, or mail it to NDSS96, 12020 Sunrise Valley Drive, Suite 210, Reston, VA, 22091, USA --------------------------------------------------------------------------- Personal Information __Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle First Name: __________________________ Middle Name: _______________ Family Name: __________________________ __sr __jr __II __III __PhD Please enter your name as you would like it to appear on your conference name tag. Badge Name: _____________________________ Contact Information Your title: _____________________________ Your affiliation: _____________________________ Your address: _____________________________ _____________________________ City: _____________________________ State or Province: _____________________________ Postal Code: _____________ Country: _____________________________ Tel (work) Number: _____________________________ Tel (home) Number: _____________________________ Fax Number: _____________________________ EMail address: _____________________________ Special Needs? Do you have any special needs (vegetarian meals, wheelchair access, etc?): _________________________________________________________________________ _________________________________________________________________________ Appear on the Registrants List? ___ Please check here if you would NOT like your name included in the list of registrants. Payment Information All Payments must be in United States Dollars. Conference Charges If you are an Internet Society member, you are eligible for a reduced registration fee. Non-member symposium attendees will receive a one year Internet Society membership as part of the non-member registration fees. Check one: Before After January 19 January 19 ---------- ---------- ___Internet Society Member Conference Fee US$ 295.00 US$ 365.00 ___Non-Member Conference Fee US$ 330.00 US$ 400.00 Method of Payment 1. __ Check Make payable to the Internet Society. Checks must be postmarked before February 16, 1996 or you will not be registered. 2. __ Credit Card __ American Expres __ Mastercard __ Visa Name on Credit Card:__________________________ Credit Card Number:__________________________ Expiration Date:__________ 3. __ First Virtual First Virtual Account Number: _________________________ 4. __ Wire Transfer* Riggs Bank of Virginia Bank ABA number: 056001260 8315 Lee Highway Account number: Internet Society 148 387 10 Fairfax VA 22031 USA Wire Transfer Confirmation Number:____________________________ * Please process wire transfer before sending the registration form. 5. __ U.S. Government Purchase order* Please provide the P.O. Number: ___________________________ * Please fax or mail a copy of your purchase order along with your registration form. Cancellation Policy ------------------- Refunds will be issued for cancellations received before February 16, 1996. No refunds will be issued after February 16, 1996. --------------------------------------------------------------------------- From firewalls-owner Mon Dec 11 01:55:28 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id BAA25773 for firewalls-outgoing; Mon, 11 Dec 1995 01:22:05 -0800 (PST) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id BAA25681 for ; Mon, 11 Dec 1995 01:21:35 -0800 (PST) Received: by mycroft.GreatCircle.COM (8.6.10/SMI-4.1/Brent-950602) id BAA22194; Mon, 11 Dec 1995 01:21:34 -0800 Message-Id: <199512110921.BAA22194@mycroft.GreatCircle.COM> Received: from hydra.dra.hmg.gb(192.5.29.32) by mycroft via smap (V1.3mjr) id sma022192; Mon Dec 11 01:21:30 1995 Received: from woodpc.dra.hmg.gb by hydra.dra.hmg.gb with SMTP ; Mon, 11 Dec 95 09:17:46 GMT X-Sender: jwood@hydra.dra.hmg.gb X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Dec 1995 09:15:49 +0000 To: From: John Wood Subject: Re: selection criteria? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 14:05 07/12/95 GMT, Johnson-Bryden, Ian wrote: > > > Stuff deleted > >Of course it all gets interesting when someone like Microsoft sees the light >and takes Windows NT for an earth shattering Orange Book C2 and then starts >to market this 'highly secure' product. That puts it on a par with virtually >all flavours of standard UNIX. Wonder how long before they bite the bullet >and try walking it through ITSEC/iCC for an earth shattering E2 ticket. I >would be interested to see if it could make it. Most US C2 products end up >requiring some major enhancements to pass the theoretically equivalent ITSEC >grade. >Ian J-B > > Windows NT 3.51 is being evaluated under ITSEC to F-C2/E3, as a server/workstation distributed system. See UK ITSEC Certified Product List October 1995. John From firewalls-owner Mon Dec 11 02:30:33 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA27543 for firewalls-outgoing; Mon, 11 Dec 1995 02:08:35 -0800 (PST) Received: from cr-am.rnp.br (peixe-boi.cr-am.rnp.br [200.17.53.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id CAA27537 for ; Mon, 11 Dec 1995 02:08:13 -0800 (PST) Received: from kerberos ([200.17.53.22]) by cr-am.rnp.br (4.1/SMI-4.1) id AA05971; Mon, 11 Dec 95 02:02:25 WDT Received: by kerberos with Microsoft Mail id <01BAC762.6ECC11A0@kerberos>; Mon, 11 Dec 1995 00:48:48 -0200 Message-Id: <01BAC762.6ECC11A0@kerberos> From: "Gedeon J. dos Santos Filho" To: "'firewalls-digest@GreatCircle.COM'" Subject: firewalls-digest Date: Mon, 11 Dec 1995 00:46:18 -0200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk firewalls-digest From firewalls-owner Mon Dec 11 02:54:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA28815 for firewalls-outgoing; Mon, 11 Dec 1995 02:47:13 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id CAA28809 for ; Mon, 11 Dec 1995 02:47:09 -0800 (PST) Received: from splinter.rtp.dg.com by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA25379; Mon, 11 Dec 1995 05:48:13 -0500 Received: by splinter (8.6.10/rtp-s04) id KAA20924; Mon, 11 Dec 1995 10:47:07 GMT From: spencerj@dg-rtp.dg.com (Jon Spencer) Message-Id: <199512111047.KAA20924@splinter> Subject: Re: selection criteria? To: jwood@hydra.dra.hmg.gb (John Wood) Date: Mon, 11 Dec 95 5:47:04 EST Cc: firewalls@greatcircle.com In-Reply-To: <199512110921.BAA22194@mycroft.GreatCircle.COM>; from "John Wood" at Dec 11, 95 9:15 am X-Mailer: ELM [version 2.3 PL11] Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > > At 14:05 07/12/95 GMT, Johnson-Bryden, Ian wrote: > > > > > > Stuff deleted > > > >Of course it all gets interesting when someone like Microsoft sees the light > >and takes Windows NT for an earth shattering Orange Book C2 and then starts > >to market this 'highly secure' product. That puts it on a par with virtually > >all flavours of standard UNIX. Wonder how long before they bite the bullet > >and try walking it through ITSEC/iCC for an earth shattering E2 ticket. I > >would be interested to see if it could make it. Most US C2 products end up > >requiring some major enhancements to pass the theoretically equivalent ITSEC > >grade. > >Ian J-B > > > > > > Windows NT 3.51 is being evaluated under ITSEC to F-C2/E3, as a > server/workstation distributed system. See UK ITSEC Certified Product List > October 1995. > > John And while you are there, look at the E4/F-B2+ certification activity for DG/UX. Also look for the Virus Prevention claim in the next ITSEC CPL (they mistakenly left it out of this last one, since prior to this they had rejected any and all virus-related claims). -- Jon F. Spencer spencerj@rtp.dg.com (uunet!rtp.dg.com!spencerj) Data General Corp. Phone : (919)248-6246 62 T.W. Alexander Dr, MS #119 FAX : (919)248-6108 Research Triangle Park, NC 27709 Office RTP 121/9 Reality is an illusion - perception is what counts. No success can compensate for failure at home. President David O. McKay ***** UCC 1-207 ******** From firewalls-owner Mon Dec 11 05:54:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id FAA03084 for firewalls-outgoing; Mon, 11 Dec 1995 05:53:08 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id FAA03079 for ; Mon, 11 Dec 1995 05:53:04 -0800 (PST) Date: Mon, 11 Dec 1995 8:54:10 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951211085410.20220a99@hobbes.orl.mmc.com> Subject: re: Timing Attack Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >I've just released details of an attack many of you will find >interesting since quite a few existing cryptography products and >systems are potentially at risk. Interesting & is exactly the type of attack that Orange Book "covert channels" addresses. However, it seems to require not only physical access to the machine executing the key manipulations but also the ability to determine when each successive bit of the calculation is complete. In that case, why not just read the key from the registers ? I do not see how such information could be extracted from a network connection. Warmly, Padgett (somehow am reminded of _Hot Pursuit II_ where the kid's dad is trying to climb a fence while his buddy just walks through the gate.) ps ftp.cryptography.com must be using "unusual" ports. Was easier to use Netscape to www.cryptography.com & just have it retrieve/print the .html From firewalls-owner Mon Dec 11 06:24:26 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA03241 for firewalls-outgoing; Mon, 11 Dec 1995 06:04:26 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA03236 for ; Mon, 11 Dec 1995 06:04:22 -0800 (PST) Date: Mon, 11 Dec 1995 9:05:28 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951211090528.20220a99@hobbes.orl.mmc.com> Subject: re: Firewall for RAS Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >I'm setting up a comm. server running NT 3.51 w/ SP2 with a internal >Digiboard attached to it. I'll use US Robotics modems, 28.8 and the >dialback security of RAS. Make sure the dialback cannot be spoofed by a caller who does not hang up but has a recording of a dialtone (ground start vs ground loop). The FCC order mandating Nationwide Caller-ID became effective 1 December (California got a 6 month extension) - does yours work ? Are you refusing "blocked" calls ? Warmly, Padgett ps Just to avoid the questions, the Caller-ID FAQ is in the TELECOM archives on LCS.MIT.EDU. You will also find the Procomm .ASP "proof of principle" I wrote a couple of years ago to demonstrate how CNID authenticated logins work. IT IS NOT A COMMERCIAL PRODUCT, was something I looked into way back when far enough to be sure it worked and then went on to more interesting things. From firewalls-owner Mon Dec 11 06:54:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA04289 for firewalls-outgoing; Mon, 11 Dec 1995 06:44:05 -0800 (PST) Received: from ritig1.rit.reuters.com (ritig1.rit.reuters.com [199.171.195.11]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id GAA04277 for ; Mon, 11 Dec 1995 06:44:00 -0800 (PST) Received: from ritig4.rit.reuters.com by ritig1.rit.reuters.com; (5.65v3.2/1.1.8.2/14Sep94-0947PM) id AA12182; Mon, 11 Dec 1995 09:46:28 -0500 Received: from mr.rit.reuters.com by RITIG4.RIT.REUTERS.COM (PMDF V4.3-10 #7805) id <01HYODFR3QC0002NA3@RITIG4.RIT.REUTERS.COM>; Mon, 11 Dec 1995 09:45:12 -0500 (EST) Received: with PMDF-MR; Mon, 11 Dec 1995 14:42:38 EST Mr-Received: by mta REC.MUAS; Relayed; Mon, 11 Dec 1995 14:42:38 -0500 Mr-Received: by mta RE5; Relayed; Mon, 11 Dec 1995 14:42:42 -0500 Mr-Received: by mta RITIG4; Relayed; Mon, 11 Dec 1995 14:45:08 -0500 Disclose-Recipients: prohibited Date: Mon, 11 Dec 1995 14:42:38 -0500 (EST) From: malcolm melville 071 510 8472 Subject: MS password cracker To: firewalls Message-Id: <6038421411121995/A58212/RE5/119C5BAA2500*@MHS> Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Importance: normal Sensitivity: Company-Confidential Ua-Content-Id: 119C5BAA2500 X400-Mts-Identifier: [;6038421411121995/A58212/RE5] Hop-Count: 2 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I know that this maybe the wrong list to ask on, but does anyone have any information on protective measures against the .PWL cracker? Is there a list/newsgroup somehere that is keeping up to speed on this one. We have rung MS and they cannot confirm or deny that there is a security breach - well I think we know better since the program worked on the .PWL files we tried it against. Have MS admitted to a breach anywhere yet - maybe its not too serious a problem to retrieve passwords subsecond? regards malcolm From firewalls-owner Mon Dec 11 07:26:15 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA04863 for firewalls-outgoing; Mon, 11 Dec 1995 07:10:08 -0800 (PST) Received: from usia.gov (XGATE.USIA.GOV [198.67.64.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA04858 for ; Mon, 11 Dec 1995 07:10:05 -0800 (PST) Received: from NetWare MHS (SMF70) by usia.gov via Connect2-SMTP 4.00; Mon, 11 Dec 95 10:10:20 -0500 Message-ID: Date: Mon, 11 Dec 95 10:06:33 -0500 From: "Lehrer, Neil" Organization: USIA To: firewalls@greatcircle.com Subject: solaris on intel X-mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Sender: firewalls-owner@GreatCircle.COM Precedence: bulk hi, any comments on solaris on intel from a security point of view? i am considering firewall-1 and since it loads on top of solaris any comments would be useful. cc to my email would be appreciated. Regards +++++++++++++++++++++++++++++++++++++++ + Neil Lehrer + U.S. Information Agency + Networks and Systems Support Division + + voice 202 619-0903 + fax 202 619-3883 + internet nlehrer@usia.gov + + "oh what a tangled net we weave + when we seek to retrieve." + +++++++++++++++++++++++++++++++++++++++ From firewalls-owner Mon Dec 11 07:54:26 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA05321 for firewalls-outgoing; Mon, 11 Dec 1995 07:28:51 -0800 (PST) Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA05310 for ; Mon, 11 Dec 1995 07:28:45 -0800 (PST) Received: from ilosrv.ilo.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA28279; Mon, 11 Dec 1995 07:21:32 -0800 Received: from ilofrs.ilo.dec.com by ilosrv.ilo.dec.com; (5.65/1.1.8.2/12Nov94-8.2MPM) id AA24977; Mon, 11 Dec 1995 15:20:34 GMT Received: by fwsrtr.fws.ilo.dec.com; (5.65/1.3/10May95) id AA27198; Mon, 11 Dec 1995 15:22:49 GMT Received: from localhost by philby.fws.ilo.dec.com; (5.65/1.1.8.2/31Aug95-8.2MPM) id AA08381; Mon, 11 Dec 1995 15:19:47 GMT Message-Id: <9512111519.AA08381@philby.fws.ilo.dec.com> To: firewalls@greatcircle.com Subject: Re: Timing Attack In-Reply-To: Your message of "Mon, 11 Dec 1995 08:54:10 EST." <951211085410.20220a99@hobbes.orl.mmc.com> X-Mailer: exmh version 1.4.1 7/21/94 Date: Mon, 11 Dec 1995 15:19:40 +0000 From: "Frank O'Dwyer" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > >I've just released details of an attack many of you will find > >interesting since quite a few existing cryptography products and > >systems are potentially at risk. > > Interesting & is exactly the type of attack that Orange Book "covert > channels" addresses. > > However, it seems to require not only physical access to the machine > executing the key manipulations but also the ability to determine when > each successive bit of the calculation is complete. In that case, why not > just read the key from the registers ? I do not see how such information > could be extracted from a network connection. >From the description, it sounds like all you need some "better than random guess" at how long en/decryption takes. And that's certainly possible without physical access. For example, if you view a remote server as an en/decrypting 'black box' (among other things) then you can give it work to do, and observe the response time. Then you give it some slightly different work to do, and observe that response time. If you do this enough times, you can presumably build up a statistical picture of how long en/decryption takes, discarding common influences such as the speed of the box, server type, network latency, etc. Some of the research on network time protocols could be useful there. Given relative encryption/decryption times (or a good guess at them), you should be able to make some statistical assertions about the key (e.g. how many, and perhaps which, bits "tend to be on" in the key). This won't give you the key, but it does tell you which areas to "search first" in a brute force attack, thus making the key's effective length shorter. Thus, key material is "leaked". (Disclaimer: I'm not a cryptanalyst. I have implemented RSA, though, and I know that it is very sensitive--for example--to the number of 'zero' bits in the exponent as far as timing goes. That's why RSA encryption can be _much_ faster than RSA decryption. The public exponent is often fixed at 17 bits, even if the private exponent may be 512 bits or more. Use of the public key is correspondingly faster.). Cheers, Frank O'Dwyer From firewalls-owner Mon Dec 11 07:58:22 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id GAA03215 for firewalls-outgoing; Mon, 11 Dec 1995 06:02:45 -0800 (PST) Received: from ALABAMA.CF.CS.YALE.EDU (RT-GW.CS.YALE.EDU [128.36.0.13]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id GAA03210 for ; Mon, 11 Dec 1995 06:02:41 -0800 (PST) From: long-morrow@CS.YALE.EDU Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU (8.7.1/res.host.cf-4.0) with ESMTP id JAA07678; Mon, 11 Dec 1995 09:03:41 -0500 (EST) sender long-morrow@CS.YALE.EDU for Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-8.7.1/res.client.cf-4.0) id JAA11401; Mon, 11 Dec 1995 09:03:39 -0500 (EST) Date: Mon, 11 Dec 1995 09:03:39 -0500 (EST) Message-Id: <199512111403.JAA11401@SPARKY.CF.CS.YALE.EDU> To: firewalls@GreatCircle.COM, frostbit@brainlink.com Subject: Re: SSL'd WU-FTPd Sender: firewalls-owner@GreatCircle.COM Precedence: bulk root wrote: > Q2) Anyone have leads on a cheap S/Key calculator?? laptops are > cumbersome and paper printouts a major risk... A graduate student here spent some time working on porting the S/Key code (the client authenticator) to the Apple Newton but said it was a pain arithmetic-wise because the S/Key code relies on 32 bit integers and the Apple Newton uses 30 bit integers (the remaining 2 bits of each int are used by the Newton's "tagged" architecture). I believe he had to create his own library of math routines to handle the problem. Has anyone else considered a PDA S/Key version? - Morrow From firewalls-owner Mon Dec 11 08:24:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA06841 for firewalls-outgoing; Mon, 11 Dec 1995 08:07:23 -0800 (PST) Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.6]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA06829 for ; Mon, 11 Dec 1995 08:07:18 -0800 (PST) Received: from smtpgty.saicuk.co.uk by flow.pipex.net with SMTP (PP); Mon, 11 Dec 1995 16:07:49 +0000 Received: by smtpgty.saicuk.co.uk with Microsoft Mail id <30CC5581@smtpgty.saicuk.co.uk>; Mon, 11 Dec 95 16:00:01 GMT From: "Johnson-Bryden, Ian" To: "'firewalls@greatcircle.com'" Subject: Re: selection criteria? Date: Mon, 11 Dec 95 14:51:00 GMT Message-ID: <30CC5581@smtpgty.saicuk.co.uk> X-Mailer: Microsoft Mail V3.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk From: firewalls-owner To: firewalls Subject: Re: selection criteria? Date: Monday, December 11, 1995 9:15AM At 14:05 07/12/95 GMT, Johnson-Bryden, Ian wrote: > > > Stuff deleted > >Of course it all gets interesting when someone like Microsoft sees the light >and takes Windows NT for an earth shattering Orange Book C2 and then starts >to market this 'highly secure' product. That puts it on a par with virtually >all flavours of standard UNIX. Wonder how long before they bite the bullet >and try walking it through ITSEC/iCC for an earth shattering E2 ticket. I >would be interested to see if it could make it. Most US C2 products end up >requiring some major enhancements to pass the theoretically equivalent ITSEC >grade. >Ian J-B > > Windows NT 3.51 is being evaluated under ITSEC to F-C2/E3, as a server/workstation distributed system. See UK ITSEC Certified Product List October 1995. John ****************************************************** True, Microsoft has 2 products being presented for evaluation according to the October issue of UKSP06; Windows NT Workstation V3,51 and Windows NT Server. Both evaluations being carried out by the EDS CLEF, and only NT Workstation being listed under 'Products at a Glance'. The TOE is interesting in that Assurance is shown as E3 and functionality only at F-C2. Could of course be a typo yet to be corrected in the next UKSP06 (F-B1 instead of F-C2, or E2 instead of E3). Generally, no product entering evaluation has been failed under ITSEC, but many have had a rough ride and ended up being modified significantly. Evaluation has also been over an extended period. At least one vendor before has submitted a product with an ambitious TOE and I believe the product may still technically be under evaluation. Initially, no CLEF or Scheme Body was permitted to talk about any product until it had completed evaluation and a certificate been issued. There were two very good reasons for that position; a product might fail but some users could have regarded an 'Under Evaluation' label to mean it was sure to pass; also there is nothing to govern the period of evaluation. That potentially means that a vendor *could* present a product today for evaluation with an very ambitious TOE and start marketing the claimed performance but deliberately delay the evaluation, effectively withdrawing from active evaluation at stage 2, but neither the Scheme Body nor the CLEF would be free to make any comment. I wouldnt of course suggest that a company with Microsoft's reputation would do anything so unethical for mere marketing advantage. Theoretically, the CLEF is supposed to carryout an informal assessment of product before quoting for evaluation and signing the contract with the vendor. In reality, all the CLEF usually receives is a draft TOE which is the vendor's claim and not necessarily backed up by any other documentation, and some CLEFs will provide quotations (and probably accept contract exchanges) off a marketing document description of the product. For those reasons, I was never happy to see the UK Scheme Body introducing a document which listed products 'under evaluation' alongside products which had been evaluated successfully and certified. I can understand that the Scheme Body was under heavy vendor pressure and was also keen to expand the size of UKSP06 for political reasons, but the change to listing products 'under evaluation' can be very misleading. For example, some vendors might claim an E3 evaluation as including Orange Book B2 functionality which is why it is particularly interesting to see someone claiming E3 as a target but only C2 for functionality. The DG-UX claim, for example, looks more logical in that they are aiming for E4 Assurance and B2 Functionality. General experience shows that a well documented and presented operating system with a realistic TOE will run through to certification in around 6 months. Some products have achieved TCSEC B1 but required considerable rewriting of documentation and some product changes to meet the theoretically equivalent ITSEC level. That has led to extended evaluation periods. There are two other words of caution. Because of the way ITSEC operates, it is important to understand what a certificate means and not just accept that a firewall has to be E4, or whatever, and then assume that every product with an E4 certificate is fine for a specific purpose. The other thing to remember is that an ITSEC Scheme Secretariat issuing a certificate gives no warrantee through that certificate. As Karen recently suggested in talking about people wishing to transact business with her, its 'buyer beware'. Ian J-B From firewalls-owner Mon Dec 11 08:58:58 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA08012 for firewalls-outgoing; Mon, 11 Dec 1995 08:49:39 -0800 (PST) Received: from mail.Clark.Net (mail.clark.net [168.143.0.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id IAA08005 for ; Mon, 11 Dec 1995 08:49:35 -0800 (PST) Received: from clark.net (proberts@clark.net [168.143.0.7]) by mail.Clark.Net (8.7.3/8.6.5) with ESMTP id LAA27754; Mon, 11 Dec 1995 11:50:37 -0500 (EST) Received: (from proberts@localhost) by clark.net (8.7.1/8.7.1) id LAA15610; Mon, 11 Dec 1995 11:50:29 -0500 (EST) Date: Mon, 11 Dec 1995 11:50:27 -0500 (EST) From: "Paul D. Robertson" To: malcolm melville 071 510 8472 cc: firewalls@greatcircle.com Subject: Re: MS password cracker In-Reply-To: <6038421411121995/A58212/RE5/119C5BAA2500*@MHS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Mon, 11 Dec 1995, malcolm melville 071 510 8472 wrote: > Date: Mon, 11 Dec 1995 14:42:38 -0500 (EST) > From: malcolm melville 071 510 8472 > To: firewalls > Subject: MS password cracker > > I know that this maybe the wrong list to ask on, but does anyone have any > information on protective measures against the .PWL cracker? Is there a > list/newsgroup somehere that is keeping up to speed on this one. > > We have rung MS and they cannot confirm or deny that there is a security breach > - well I think we know better since the program worked on the .PWL files we > tried it against. Have MS admitted to a breach anywhere yet - maybe its not too > serious a problem to retrieve passwords subsecond? > It's been confirmed on MS' page, http://wwww.microsoft.com/windows/pr/password.htm, (though a search of the MS homepage doesn't retrieve it). Basically, MS is saying to turn off the registry until they have a fix out (Mid Dec is the current claim). Paul. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts@clark.net which may have no basis whatsoever in fact." PSB#9280 From firewalls-owner Mon Dec 11 09:24:27 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA08473 for firewalls-outgoing; Mon, 11 Dec 1995 09:01:54 -0800 (PST) Received: from halsp.hitachi.com (unknown-112-2.halsp.hitachi.com [198.70.112.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id JAA08468 for ; Mon, 11 Dec 1995 09:01:49 -0800 (PST) Received: from ahi.halsp.hitachi.com ([137.168.6.111]) by halsp.hitachi.com (5.x/SMI-4.1) id AA11860; Mon, 11 Dec 1995 09:04:54 -0800 Received: from coho by ahi.halsp.hitachi.com (4.1/SMI-4.1) id AB08509; Mon, 11 Dec 95 09:04:39 PST Message-Id: <30CC643E.4E3E@halsp.hitachi.com> Date: Mon, 11 Dec 1995 09:02:54 -0800 From: Eric Vanuska X-Mailer: Mozilla 2.0b1 (X11; I; HP-UX A.09.05 9000/710) Mime-Version: 1.0 To: Paul Ferguson Cc: Jon Doran , firewalls@GreatCircle.COM Subject: Re: modems and accessing the internal network References: <199512110017.QAA28077@lint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Paul Ferguson wrote: > > At 03:12 PM 12/10/95 -0700, Jon Doran wrote: > > >I would like to hear everyone's comments on modem pool placement. > > SNIP > > As long as you authenticate dial-in access, then its not an end-run. :-) I believe it is!! > > Its certainly more palatable, in my opinion, than any placment on an > external network, where the possibility exists of someone compromising > the external network and sniffing packets for passwords. How are internal modems less susceptible to compromise than external modems? It seems to me that using authentication can be done just as easily for modems outside the firewall, as for those inside. As far as sniffing goes, which is more damaging, sniffing an external network, versus the internal network, would depend on what you're letting through your firewall and other traffic patterns. Our solution was to use an idea from Chapman/Zwicky. They show a diagram with a vendor DMZ and an internet DMZ. Why not create a dial-in DMZ? Okay, cost and complexity are two possiblities. Never the less, it seems that some sort of filter mechanism (proxy server or router) is a must for analog dial-in users. As others have pointed out, analog modems can be compromised, even when using dial-back. ericv > > - paul > > -- > Paul Ferguson || || > Consulting Engineering || || > Reston, Virginia USA |||| |||| > tel: +1.703.716.9538 ..:||||||:..:||||||:.. > e-mail: pferguso@cisco.com c i s c o S y s t e m s From firewalls-owner Mon Dec 11 09:39:35 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id HAA05136 for firewalls-outgoing; Mon, 11 Dec 1995 07:25:42 -0800 (PST) Received: from su1.in.net (su1.in.net [199.0.62.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id HAA05131 for ; Mon, 11 Dec 1995 07:25:38 -0800 (PST) Received: from pm2-02.in.net by su1.in.net with SMTP (5.65/1.2-eef) id AA24211; Mon, 11 Dec 95 10:26:06 -0500 Date: Mon, 11 Dec 95 10:26:06 -0500 Message-Id: <9512111526.AA24211@su1.in.net> X-Sender: frankw@in.net X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: jon@ctasim.com (Jon Doran) From: frankw@in.net (Frank Willoughby) Subject: Re: modems and accessing the internal network Cc: firewallS@GreatCircle.com Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Jon Doran wrote: >I would like to hear everyone's comments on modem pool placement. Brent >and Elizabeth suggest in their book to place them on the internal network >and protect them really well. > >Hmm, does anyone else have a problem with this? To me the purpose of the >firewall is to protect the internal network by providing a clear separation >between the internal and external networks. I really don't like the idea >of allowing an end-run around the Bastion hosts. I would recommend that dialin connections *NOT* be placed directly on the internal network, because: o There is no way of guaranteeing that the systems dialing in are not connected to another network (which opens up a real can of worms - legal, privacy, security, etc). o I would also like to have some control over the services they have to my network. o Extensive logging of communications activity should also be achieved - including which system was accessed, how, what was uploaded/downloaded, etc. One way of handling this would be to have an Application-level firewall which has the capabiity of subnetting. Put your modem bank on one of the subnets & use the firewall to authenticate the calling party, provide adequate filtering, & encrypt the traffic end-to-end. (For security reasons, the firewall should really perform all 3 functions). At this point, the incoming connection could be directed to an internal system, the Internet, or whatever. Best Regards, Frank Fortified Networks Inc. - Management & Information Security Consulting Phone: (317) 573-0800 - http://www.fortified.com/fortified The opinions expressed above are of the author and may not necessarily be representative of Fortified Networks Inc. From firewalls-owner Mon Dec 11 09:54:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id IAA08225 for firewalls-outgoing; Mon, 11 Dec 1995 08:56:00 -0800 (PST) Received: from mycroft.GreatCircle.COM (mycroft.greatcircle.com [198.102.244.35]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id IAA08220 for ; Mon, 11 Dec 1995 08:55:57 -0800 (PST) Received: by mycroft.GreatCircle.COM (8.6.10/SMI-4.1/Brent-950602) id IAA24081; Mon, 11 Dec 1995 08:55:55 -0800 Message-Id: <199512111655.IAA24081@mycroft.GreatCircle.COM> Received: from hydra.dra.hmg.gb(192.5.29.32) by mycroft via smap (V1.3mjr) id sma024077; Mon Dec 11 08:55:42 1995 Received: from woodpc.dra.hmg.gb by hydra.dra.hmg.gb with SMTP ; Mon, 11 Dec 95 16:55:17 GMT X-Sender: jwood@hydra.dra.hmg.gb X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Dec 1995 16:53:20 +0000 To: firewalls@greatcircle.com From: John Wood Subject: Re: selection criteria? Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 14:51 11/12/95 GMT, Johnson-Bryden, Ian wrote: > > > Stuff deleted > > The TOE is >interesting in that Assurance is shown as E3 and functionality only at F-C2. >Could of course be a typo yet to be corrected in the next UKSP06 (F-B1 >instead of F-C2, or E2 instead of E3). > I don't think it's a typo. One big advantage of ITSEC over Orange Book is that functionality and assurance are completely separated. You can claim very high assurance for very simple functionality, or low assurance for high functionality. The F-C2 bit is only a rough claim of functionality, and you really have to read the Target of Evaluation to find out exactly what's being evaluated and what isn't. This makes ITSEC good for evaluating firewalls, for example, because you can claim the exact functionality needed for the firewall in the TOE, and it gets evaluated, instead of trying to bend the Orange Book and TNI to situations they were never designed for. Some people have tried to provide an equivalence between ITSEC E numbers and Orange Book markings (E3=B1 etc.), but it should only be taken as a rough comparison of assurance levels, not functionality. Regards John From firewalls-owner Mon Dec 11 10:24:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA10752 for firewalls-outgoing; Mon, 11 Dec 1995 10:21:05 -0800 (PST) Received: from nsco.network.com (nsco.network.com [129.191.1.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA10708 for ; Mon, 11 Dec 1995 10:20:25 -0800 (PST) Received: from mnbp.network.com (ushub.network.com) by nsco.network.com (4.1/1.34) id AA15991; Mon, 11 Dec 95 12:22:43 CST Received: by mnbp.network.com with Microsoft Mail id <30CC7667@mnbp.network.com>; Mon, 11 Dec 95 12:20:23 CST From: Craig McLellan To: firewalls Subject: RE: X.25 Firewall Date: Mon, 11 Dec 95 12:19:00 CST Message-Id: <30CC7667@mnbp.network.com> X-Mailer: Microsoft Mail V3.0 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Check out Network Systems BorderGuard and Security Router. WWW.NETWORK.COM RGRDS....clm ---------- From: firewalls-owner To: firewalls Subject: X.25 Firewall Date: Friday, December 08, 1995 12:00AM Message: What firewalls are there that can handle X.25, SNA and TCP/IP. Thanks In Anticipation From firewalls-owner Mon Dec 11 10:52:09 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id KAA11863 for firewalls-outgoing; Mon, 11 Dec 1995 10:42:19 -0800 (PST) Received: from ritig1.rit.reuters.com (ritig1.rit.reuters.com [199.171.195.11]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id KAA11857 for ; Mon, 11 Dec 1995 10:42:14 -0800 (PST) Received: from ritig4.rit.reuters.com by ritig1.rit.reuters.com; (5.65v3.2/1.1.8.2/14Sep94-0947PM) id AA08798; Mon, 11 Dec 1995 13:44:44 -0500 Received: from mr.rit.reuters.com by RITIG4.RIT.REUTERS.COM (PMDF V4.3-10 #7805) id <01HYOLR55CSG002QB4@RITIG4.RIT.REUTERS.COM>; Mon, 11 Dec 1995 13:43:27 -0500 (EST) Received: with PMDF-MR; Mon, 11 Dec 1995 18:40:57 EST Mr-Received: by mta REC.MUAS; Relayed; Mon, 11 Dec 1995 18:40:57 -0500 Mr-Received: by mta RE5; Relayed; Mon, 11 Dec 1995 18:40:58 -0500 Mr-Received: by mta RITIG4; Relayed; Mon, 11 Dec 1995 18:43:22 -0500 Disclose-Recipients: prohibited Date: Mon, 11 Dec 1995 18:40:57 -0500 (EST) From: malcolm melville 071 510 8472 Subject: Re: MS password cracker In-Reply-To: To: firewalls Message-Id: <0957401811121995/A62264/RE5/119C5CA83800*@MHS> Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Importance: normal Sensitivity: Company-Confidential Ua-Content-Id: 119C5CA83800 X400-Mts-Identifier: [;0957401811121995/A62264/RE5] Hop-Count: 2 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Paul Robertson wrote: -> -> On Mon, 11 Dec 1995, malcolm melville 071 510 8472 wrote: -> -> > Date: Mon, 11 Dec 1995 14:42:38 -0500 (EST) -> > From: malcolm melville 071 510 8472 -> > To: firewalls -> > Subject: MS password cracker -> > -> > I know that this maybe the wrong list to ask on, but does anyone have any -> > information on protective measures against the .PWL cracker? Is there a -> > list/newsgroup somehere that is keeping up to speed on this one. -> > -> > We have rung MS and they cannot confirm or deny that there is a security breach -> > - well I think we know better since the program worked on the .PWL files we -> > tried it against. Have MS admitted to a breach anywhere yet - maybe its not too -> > serious a problem to retrieve passwords subsecond? -> > -> It's been confirmed on MS' page, -> http://wwww.microsoft.com/windows/pr/password.htm, (though a search of -> the MS homepage doesn't retrieve it). Basically, MS is saying to turn off the -> registry until they have a fix out (Mid Dec is the current claim). -> -> Paul. -> Hmm.. I see no solution for WfW but I guess that is as expected. Thanks for the page reference. Now back to Firewalls. Apologies for distraction. malcolm From firewalls-owner Mon Dec 11 11:22:03 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA00739 for firewalls-outgoing; Mon, 11 Dec 1995 11:02:36 -0800 (PST) Received: from mesquite.bmc.com (mesquite.bmc.com [198.147.191.116]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id LAA00732 for ; Mon, 11 Dec 1995 11:02:31 -0800 (PST) Received: from ripken.bmc.com.bmc.com (ripken.bmc.com) by mesquite.bmc.com with SMTP (1.37.109.16/16.2) id AA242008433; Mon, 11 Dec 1995 13:00:33 -0600 Received: by ripken.bmc.com.bmc.com (5.x/SMI-SVR4) id AA05191; Mon, 11 Dec 1995 13:01:31 -0600 From: cbriese@ripken.bmc.com (Chuck Briese) Message-Id: <9512111301.ZM5189@ripken.bmc.com> Date: Mon, 11 Dec 1995 13:01:30 -0600 In-Reply-To: frankw@in.net (Frank Willoughby) "Re: modems and accessing the internal network" (Dec 11, 10:26) References: <9512111526.AA24211@su1.in.net> X-Mailer: Z-Mail (3.2.0 06sep94) To: frankw@in.net (Frank Willoughby) Subject: Re: modems and accessing the internal network Cc: firewallS@GreatCircle.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Dec 11, 10:26, Frank Willoughby wrote: > Subject: Re: modems and accessing the internal network > > I would recommend that dialin connections *NOT* be placed directly on the > internal network, because: > > o Extensive logging of communications activity should also be achieved - > including which system was accessed, how, what was uploaded/downloaded, > etc. > > One way of handling this would be to have an Application-level firewall > which has the capabiity of subnetting. Put your modem bank on one of > the subnets & use the firewall to authenticate the calling party, provide > adequate filtering, & encrypt the traffic end-to-end. (For security > reasons, the firewall should really perform all 3 functions). At this > point, the incoming connection could be directed to an internal system, > the Internet, or whatever. >-- End of excerpt from Frank Willoughby While I agree wholeheartedly in the concept, how realistically can you make sure the incoming users simply don't bounce from machine to machine once they reach the internal net? How do you log all of that activity? Also, how do you stop unauthorized access from a machine once the party is authenticated by the firewall? The user authenticates, and then anyone who has access to the machine has access to the internal net. I don't like this situation, and I can only throw policy at it to keep it from occurring. -- Chuck Briese, striving for zero defects in an inherently defective world BMC Software, Inc., 2101 City West Blvd., Houston 77042 (713) 918-1216 From firewalls-owner Mon Dec 11 11:50:51 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id JAA09283 for firewalls-outgoing; Mon, 11 Dec 1995 09:24:29 -0800 (PST) Received: from safety.worldcom.com (safety.worldcom.com [198.64.193.5]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id JAA09261 for ; Mon, 11 Dec 1995 09:24:21 -0800 (PST) Received: (from smtp@localhost) by safety.worldcom.com (8.7.1/8.6.9) id KAA29180 for ; Mon, 11 Dec 1995 10:56:49 -0600 (CST) Received: from worldcom-45.worldcom.com(198.64.193.76) by safety.worldcom.com via smap (V1.3) id sma028812; Mon Dec 11 10:52:28 1995 Received: by worldcom-45.worldcom.com (IBM OS/2 SENDMAIL VERSION 1.3.14/3.3) id AA2350; Mon, 11 Dec 95 10:53:02 -0500 Message-Id: <9512111553.AA2350@worldcom-45.worldcom.com> Received: from worldcom with "Lotus Notes Mail Gateway for SMTP" id 16275B57C8FE38818625628F005C9629; Mon, 11 Dec 95 10:53:01 To: firewalls From: Kenneth Smith Date: 11 Dec 95 8:44:24 Subject: Re: MS password cracker Mime-Version: 1.0 Content-Type: Text/Plain Sender: firewalls-owner@GreatCircle.COM Precedence: bulk This is the first I've heard of this -- although I'm not terribly surprised, given that it's such an obvious point of attack on WFW machines (and so can be used as a launch point for more serious attacks). Where can I get more information on this? Ken Smith MIS Operations Manager Independent National Mortgage Pasadena, CA 91101 _____________________ To: firewalls @ GreatCircle.COM @ Internet cc: (bcc: Kenneth Smith) From: malcolm.melville @ reuters.com (malcolm melville 071 510 8472) @ Internet @ WORLDCOM Date: 12/11/95 02:42:38 PM CST Subject: MS password cracker I know that this maybe the wrong list to ask on, but does anyone have any information on protective measures against the .PWL cracker? Is there a list/newsgroup somehere that is keeping up to speed on this one. We have rung MS and they cannot confirm or deny that there is a security breach - well I think we know better since the program worked on the .PWL files we tried it against. Have MS admitted to a breach anywhere yet - maybe its not too serious a problem to retrieve passwords subsecond? regards malcolm From firewalls-owner Mon Dec 11 11:52:06 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA02312 for firewalls-outgoing; Mon, 11 Dec 1995 11:47:03 -0800 (PST) Received: from gw.lsli.com (lsli.sccsi.com [198.65.130.22]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA02307 for ; Mon, 11 Dec 1995 11:46:58 -0800 (PST) From: ted@lsli.com Received: by gw.lsli.com (AIX 3.2/UCB 5.64/4.03) id AA15819; Mon, 11 Dec 1995 13:36:14 -0600 Received: by lsli.com via smwrap Version 2.1 id smwrapPMkA2e; Mon Dec 11 13:35:45 1995 id AA19806; Mon, 11 Dec 1995 13:37:38 -0600 Date: Mon, 11 Dec 95 13:46:14 PST Subject: RE: HP-UX Based 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 On Fri, 08 Dec 1995 14:41 EST jwojn@telxon.mis.telxon.com wrote: > > >To All: > >My company is considering an HP-UX machine to act as our new firewall, due >to the high performance of these units. Does anyone have any information >regarding commercial firewalls for the HP-UX environment? There are three >that I know of: Eagle's Raptor (which I understand is very good), ASG >(Atlantic Systems Group) and Morning Star. I haven't heard very much about >the other two, and have never seen them mentioned on this list (although I >am fairly new to this list, so I may have missed it :-) > PORTUS is also available for the HPUX platform. Cheers Ted ------------------------------------- Ted Airedale Livermore Software Laboratories, Inc. 1602 Mossy Stone Houston, Texas 77077 713-496-1580 800-240-5754 E-mail: ted@gw.lsli.com http://www.lsli.com Date: 12/11/95 ------------------------------------- From firewalls-owner Mon Dec 11 12:22:05 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA02705 for firewalls-outgoing; Mon, 11 Dec 1995 11:57:36 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA02691 for ; Mon, 11 Dec 1995 11:57:29 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id OAA27619; Mon, 11 Dec 1995 14:01:49 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id OAA27608; Mon, 11 Dec 1995 14:01:48 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id NAA26036; Mon, 11 Dec 1995 13:56:03 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id NAA07844; Mon, 11 Dec 1995 13:56:02 -0600 Date: Mon, 11 Dec 1995 13:56:02 -0600 From: Rick Smith Message-Id: <199512111956.NAA07844@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com, anton@the-wire.com Subject: Re: chroot vs TE (Was Re: William of Occam) Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Anton J Aylward writes: >The difference is that the Ptolemaic model was wrong in that it was >theoretically inadequate. The UNIX model isn't wrong, it isn't even >inadequate; its lack of application to the networking interface was >inadequate. Adequate with respect to _what_ ?? That's the question. While the alleged Unix protection model may be adequate for something, I argue that it's inadequate for a firewall because it does not enforce a *mandatory* protection in the classic sense. It isn't always invoked, it isn't tamperproof, and it is bypassable. This is *not* a slam on Unix or its builders: just an observation that we're trying to make it do something it wasn't designed to do. The firewall is the first commercial device I know of that really, really needs mandatory access controls. Mandatory controls are designed to resist attacks by overtly malicious people that really know what they're doing. They work because they draw explicit boundaries that *no* software should cross. The kernel doesn't get caught in this problem of yielding to good guys who are really bad guys playing a masquerade. Rick. smith@sctc.com secure computing corporation From firewalls-owner Mon Dec 11 12:52:02 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA01792 for firewalls-outgoing; Mon, 11 Dec 1995 11:33:52 -0800 (PST) Received: from hosaka.smallworks.com (hosaka.SmallWorks.COM [192.207.126.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA01787 for ; Mon, 11 Dec 1995 11:33:48 -0800 (PST) Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA18488; Mon, 11 Dec 1995 13:26:22 -0600 Date: Mon, 11 Dec 1995 13:26:22 -0600 From: jim@SmallWorks.COM (Jim Thompson) Message-Id: <9512111926.AA18488@hosaka.smallworks.com> To: PADGETT@hobbes.orl.mmc.com Subject: re: Timing Attack Cc: firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Padgett writes: >>I've just released details of an attack many of you will find >>interesting since quite a few existing cryptography products and >>systems are potentially at risk. > >Interesting & is exactly the type of attack that Orange Book "covert >channels" addresses. Well, sort of. >However, it seems to require not only physical access to the machine >executing the key manipulations but also the ability to determine when >each successive bit of the calculation is complete. In that case, why not >just read the key from the registers ? I do not see how such information >could be extracted from a network connection. Then you should re-read the paper. If you can watch the cryptodata flying by on the network, and measure how long the responses take, you can break the key. This is what is so disturbing about the paper. Jim From firewalls-owner Mon Dec 11 13:22:03 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA06255 for firewalls-outgoing; Mon, 11 Dec 1995 13:17:28 -0800 (PST) Received: from uu11.psi.com (uu11.psi.com [38.8.24.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA06242 for ; Mon, 11 Dec 1995 13:17:11 -0800 (PST) Received: from gate.funb.com by uu11.psi.com (5.65b/4.0.940727-PSI/PSINet) via SMTP; id AA25125 for firewalls@greatcircle.com; Mon, 11 Dec 95 16:16:12 -0500 Received: by funb.com (4.1/SMI-4.1) id AA11368; Mon, 11 Dec 95 16:16:00 EST Received: from cm_mailhost.capmark.funb.com by gate via SMTP (V1.3) id sma011361; Mon Dec 11 16:15:54 1995 Received: from funws302.capmark.funb.com (funws302 [168.175.7.54]) by cm_mailhost.capmark.funb.com (8.6.12/8.6.12) with ESMTP id QAA12315 for ; Mon, 11 Dec 1995 16:15:53 -0500 From: "Mark Horn [ Net Ops ]" Received: (mhorn@localhost) by funws302.capmark.funb.com (8.6.12/8.6.12) id QAA05754 for firewalls@greatcircle.com; Mon, 11 Dec 1995 16:15:52 -0500 Message-Id: <199512112115.QAA05754@funws302.capmark.funb.com> Subject: proxied SSL? To: firewalls@greatcircle.com Date: Mon, 11 Dec 1995 16:15:52 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 ME8] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Hello, We have a project here that is using Netscape's commerce server to do encrypted sessions from the Internet to a WWW server sitting behind our firewall. Can anyone give me a pointer to a technical description of how Netscape's commerce server does SSL? I need to provide some sort of proxy so that I can allow it through our firewall. Thanks in advance. -- Mark Horn mhorn@funb.com Free Advice and Opinions -- Refunds Available From firewalls-owner Mon Dec 11 14:36:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA06616 for firewalls-outgoing; Mon, 11 Dec 1995 13:23:52 -0800 (PST) Received: from mesquite.bmc.com (mesquite.bmc.com [198.147.191.116]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id NAA06583 for ; Mon, 11 Dec 1995 13:23:42 -0800 (PST) Received: from ripken.bmc.com.bmc.com (ripken.bmc.com) by mesquite.bmc.com with SMTP (1.37.109.16/16.2) id AA252786915; Mon, 11 Dec 1995 15:21:55 -0600 Received: by ripken.bmc.com.bmc.com (5.x/SMI-SVR4) id AA05379; Mon, 11 Dec 1995 15:22:53 -0600 From: cbriese@ripken.bmc.com (Chuck Briese) Message-Id: <9512111522.ZM5377@ripken.bmc.com> Date: Mon, 11 Dec 1995 15:22:52 -0600 In-Reply-To: H Morrow Long "Re: modems and accessing the internal network" (Dec 11, 15:10) References: <199512112010.PAA24170@ALABAMA.CF.CS.YALE.EDU> X-Mailer: Z-Mail (3.2.0 06sep94) To: H Morrow Long , cbriese@ripken.bmc.com, frankw@in.net Subject: Re: modems and accessing the internal network Cc: firewallS@GreatCircle.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Dec 11, 15:10, H Morrow Long wrote: > Subject: Re: modems and accessing the internal network > > Why not set up yet a third classification of network in addition to the > first two ( inside-corporate-trusted, outside-internet-untrusted ) > which is : "dialup-untrusted" > > You could then have the dialup network exist separate from the DMZ and > (Scenario 1) either share the same filtering router or proxy firewall > setup or (Scenario 2) have a completely different firewall between the > dialup-untrusted bank and the inside-corporate-trusted LAN. >-- End of excerpt from H Morrow Long I am an advocate of Scenario 2 because the firewall needs of the dialup/ISDN user are different from the firewall protecting the internal network from the DMZ. I can simply specify "no telnet, no X, no NFS, etc..." from the DMZ to the internal network. However, these users, particularly those with ISDN connections, require NFS and X traffic to be passed to machines at their homes/offices. While I might be able to place a firewall between the remote and internal networks, how effective would it really be? I ran across this example of what I fear in the appsrvr man page from my Pipeline software: HISTORY This command is only here because some system admins think its a great way to prevent folks from actually wanting to work via an ISDN link. -- Chuck Briese, striving for zero defects in an inherently defective world BMC Software, Inc., 2101 City West Blvd., Houston 77042 (713) 918-1216 From firewalls-owner Mon Dec 11 14:42:21 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id OAA09862 for firewalls-outgoing; Mon, 11 Dec 1995 14:16:14 -0800 (PST) Received: from hobbes.orl.mmc.com (hobbes.orl.mmc.com [141.240.192.100]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id OAA09857 for ; Mon, 11 Dec 1995 14:16:05 -0800 (PST) Date: Mon, 11 Dec 1995 17:15:23 -0500 (EST) From: "A. Padgett Peterson, P.E. Information Security" To: firewalls@greatcircle.com Message-Id: <951211171523.2021f537@hobbes.orl.mmc.com> Subject: re: Timing Attacks Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Frank rites: >From the description, it sounds like all you need some "better than >random guess" at how long en/decryption takes. And that's certainly >possible without physical access. For example, if you view a >remote server as an en/decrypting 'black box' (among other things) >then you can give it work to do, and observe the response time. Can see how that might be possible at the keyboard. Might be possible on a remote terminal with a direct connection. Cannot see how it would work on a packet based network (having enough trouble with a std deviation of 188 usec against an average difference of 17 usec.), just too many random factors involved. Warmly, Padgett From firewalls-owner Mon Dec 11 14:57:49 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id NAA06576 for firewalls-outgoing; Mon, 11 Dec 1995 13:23:13 -0800 (PST) Received: from icicle (icicle.winternet.com [198.174.169.5]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id NAA06571 for ; Mon, 11 Dec 1995 13:23:08 -0800 (PST) Received: from parka (dufresne@parka.winternet.com [198.174.169.9]) by icicle (8.6.12/8.6.12) with ESMTP id PAA00161; Mon, 11 Dec 1995 15:22:07 -0600 Received: (from dufresne@localhost) by parka (8.6.12/8.6.12) id PAA23725; Mon, 11 Dec 1995 15:22:38 -0600 Posted-Date: Mon, 11 Dec 1995 15:22:38 -0600 Date: Mon, 11 Dec 1995 15:22:37 -0600 (CST) From: Ron DuFresne To: Eric Vanuska cc: Paul Ferguson , Jon Doran , firewalls@GreatCircle.COM Subject: Re: modems and accessing the internal network In-Reply-To: <30CC643E.4E3E@halsp.hitachi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Mon, 11 Dec 1995, Eric Vanuska wrote: > Paul Ferguson wrote: > > > > At 03:12 PM 12/10/95 -0700, Jon Doran wrote: > > > > >I would like to hear everyone's comments on modem pool placement. > > > SNIP > > > > As long as you authenticate dial-in access, then its not an end-run. :-) > I believe it is!! > > > > Its certainly more palatable, in my opinion, than any placment on an > > external network, where the possibility exists of someone compromising > > the external network and sniffing packets for passwords. > How are internal modems less susceptible to compromise than external > modems? It seems to me that using authentication can be done just as easily > for modems outside the firewall, as for those inside. As far as sniffing > goes, which is more damaging, sniffing an external network, versus the internal > network, would depend on what you're letting through your firewall and other > traffic patterns. > > Our solution was to use an idea from Chapman/Zwicky. They show a diagram > with a vendor DMZ and an internet DMZ. Why not create a dial-in DMZ? Okay, > cost and complexity are two possiblities. Never the less, it seems that > some sort of filter mechanism (proxy server or router) is a must for analog > dial-in users. As others have pointed out, analog modems can be compromised, > even when using dial-back. Hmm, am I missing something? I thought sniffing worked only when directly on the ethernet, can ppp/slip connections really sniff? And while we're at it, why does everyone seem to shun dialback connections? Thanks, Ron DuFresne ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. From firewalls-owner Mon Dec 11 15:15:02 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id LAA01489 for firewalls-outgoing; Mon, 11 Dec 1995 11:22:40 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id LAA01484 for ; Mon, 11 Dec 1995 11:22:27 -0800 (PST) Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id NAA25877 for ; Mon, 11 Dec 1995 13:27:54 -0600 Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id NAA25873 for ; Mon, 11 Dec 1995 13:27:53 -0600 Received: from shade.sctc.com (shade.sctc.com [172.17.192.48]) by sphinx.sctc.com (8.7.1/8.6.10) with SMTP id NAA25439; Mon, 11 Dec 1995 13:22:16 -0600 (CST) Received: (from smith@localhost) by shade.sctc.com (8.6.12/8.6.9) id NAA06993; Mon, 11 Dec 1995 13:22:14 -0600 Date: Mon, 11 Dec 1995 13:22:14 -0600 From: Rick Smith Message-Id: <199512111922.NAA06993@shade.sctc.com> To: firewalls@greatcircle.com Cc: smith@sctc.com Subject: Re: HP-UX Based Firewalls Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Adam Shostack writes about firewall platform selection: > Choose a platform you are familiar with, and can work with. >If HP-UX is that platform, fine. Don't go for a new environment for >firewalls. This is one point of view. Another is to assess how important the firewall security measures are to your organization's integrity and choose one that offers the best protection. Commercial operating systems are designed to serve customers in typical commercial environments. Such systems are not designed to resist sophisticated attacks. If you need top notch protection, look at systems designed for security, not add-ons that live atop conventional platforms. Rick. smith@sctc.com secure computing corporation From firewalls-owner Mon Dec 11 15:21:18 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id MAA03377 for firewalls-outgoing; Mon, 11 Dec 1995 12:10:52 -0800 (PST) Received: from ALABAMA.CF.CS.YALE.EDU (RT-GW.CS.YALE.EDU [128.36.0.13]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id MAA03360 for ; Mon, 11 Dec 1995 12:10:47 -0800 (PST) Received: by ALABAMA.CF.CS.YALE.EDU id PAA24170; Mon, 11 Dec 1995 15:10:07 -0500 (EST) sender long-morrow@CS.YALE.EDU for Date: Mon, 11 Dec 1995 15:10:07 -0500 (EST) From: H Morrow Long Message-Id: <199512112010.PAA24170@ALABAMA.CF.CS.YALE.EDU> To: cbriese@ripken.bmc.com, frankw@in.net Subject: Re: modems and accessing the internal network Cc: firewallS@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Why not set up yet a third classification of network in addition to the first two ( inside-corporate-trusted, outside-internet-untrusted ) which is : "dialup-untrusted" You could then have the dialup network exist separate from the DMZ and (Scenario 1) either share the same filtering router or proxy firewall setup or (Scenario 2) have a completely different firewall between the dialup-untrusted bank and the inside-corporate-trusted LAN. Scenario 1: Internet | Terminal Server(s) | | outside-internet-untrusted DMZ dialup-untrusted | LAN ============================== ====================== | | | | | | +---------------------------+ | | | Firewall | | | +---------------------------+ | | ============================= inside-corporate-trusted LAN Scenario 2: Internet | Terminal Server(s) | | outside-internet-untrusted DMZ dialup-untrusted | LAN ============================== ====================== | | | | | | +-------------+ +-----------+ | | | | | Firewall | | Firewall | | | | | +-------------+ +-----------+ | | | | ============================= inside-corporate-trusted LAN - Morrow From firewalls-owner Mon Dec 11 15:22:04 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA12696 for firewalls-outgoing; Mon, 11 Dec 1995 15:18:40 -0800 (PST) Received: from mesquite.bmc.com (mesquite.bmc.com [198.147.191.116]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id PAA12691 for ; Mon, 11 Dec 1995 15:18:34 -0800 (PST) Received: from ripken.bmc.com.bmc.com (ripken.bmc.com) by mesquite.bmc.com with SMTP (1.37.109.16/16.2) id AA265633808; Mon, 11 Dec 1995 17:16:48 -0600 Received: by ripken.bmc.com.bmc.com (5.x/SMI-SVR4) id AA00426; Mon, 11 Dec 1995 17:17:46 -0600 From: cbriese@ripken.bmc.com (Chuck Briese) Message-Id: <9512111717.ZM424@ripken.bmc.com> Date: Mon, 11 Dec 1995 17:17:45 -0600 In-Reply-To: Ron DuFresne "Re: modems and accessing the internal network" (Dec 11, 15:22) References: X-Mailer: Z-Mail (3.2.0 06sep94) To: Ron DuFresne Subject: Re: modems and accessing the internal network Cc: firewalls@GreatCircle.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Dec 11, 15:22, Ron DuFresne wrote: > Subject: Re: modems and accessing the internal network > On Mon, 11 Dec 1995, Eric Vanuska wrote: > > Hmm, am I missing something? I thought sniffing worked only when > directly on the ethernet, can ppp/slip connections really sniff? > > And while we're at it, why does everyone seem to shun dialback connections? >-- End of excerpt from Ron DuFresne Our ISDN connection will use Caller ID to authenticate - probably about as safe as dialback. Unfortunately, the user may have a little ethernet network set up at his house, accessing both his ISP and the office at the same time. At that point our internal net would be only as secure as his network at home; it's difficult for me to enforce a security policy at that point. I can recite one all I like, it's just impossible for me to monitor. -- Chuck Briese, striving for zero defects in an inherently defective world BMC Software, Inc., 2101 City West Blvd., Houston 77042 (713) 918-1216f From firewalls-owner Mon Dec 11 15:52:05 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA13075 for firewalls-outgoing; Mon, 11 Dec 1995 15:24:33 -0800 (PST) Received: from citecuh.citec.qld.gov.au (citecuh.citec.qld.gov.au [203.5.10.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id PAA13070 for ; Mon, 11 Dec 1995 15:24:27 -0800 (PST) Received: (from mail@localhost) by citecuh.citec.qld.gov.au (8.6.10/8.6.10) id JAA19515; Tue, 12 Dec 1995 09:18:19 +1000 Received: from citecub.citec.qld.gov.au(131.242.4.98) by citecuh.citec.qld.gov.au via smap (V1.3) id /mail/incoming/sma019507; Tue Dec 12 09:18:10 1995 Received: by citecub.citec.qld.gov.au (5.0/SMI-SVR4) id AA07808; Tue, 12 Dec 1995 09:21:07 +1000 From: sgcccdc@citec.qld.gov.au (Colin Campbell) Message-Id: <9512112321.AA07808@citecub.citec.qld.gov.au> Subject: Re: modems and accessing the internal network To: cbriese@ripken.bmc.com (Chuck Briese) Date: Tue, 12 Dec 1995 09:21:06 +1000 (EST) Cc: firewallS@GreatCircle.COM In-Reply-To: <9512111301.ZM5189@ripken.bmc.com> from "Chuck Briese" at Dec 11, 95 01:01:30 pm X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk My mailer thinks Chuck Briese said: > [chomp] > > While I agree wholeheartedly in the concept, how realistically can you > make sure the incoming users simply don't bounce from machine to machine > once they reach the internal net? How do you log all of that activity? If you use a terminal server and TACACS+ to authenticate and control the users, you can set access lists that specify what commands and destinations a user can access. That way you can control who goes where. Of course that means you have to secure the boxes that they connect to from the terminal server but at least it's a start at limiting the accessibility of the internal network. > > Also, how do you stop unauthorized access from a machine once the party > is authenticated by the firewall? The user authenticates, and then anyone > who has access to the machine has access to the internal net. > > I don't like this situation, and I can only throw policy at it to > keep it from occurring. As above, you can throw a little hardware at it too :-) Colin From firewalls-owner Mon Dec 11 16:22:09 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA15694 for firewalls-outgoing; Mon, 11 Dec 1995 16:04:53 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id QAA15682 for ; Mon, 11 Dec 1995 16:04:45 -0800 (PST) Received: from rcooper.the-wire.com (rcooper.the-wire.com [198.53.159.74]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id TAA00499; Mon, 11 Dec 1995 19:03:43 -0500 Received: by rcooper.the-wire.com with Microsoft Mail id <01BAC7FB.4C895FA0@rcooper.the-wire.com>; Mon, 11 Dec 1995 19:03:04 -0500 Message-ID: <01BAC7FB.4C895FA0@rcooper.the-wire.com> From: Russ Cooper To: "'smtp:Firewalls@greatcircle.com'" , "'Goncalves, Marcus'" Subject: RE: Firewall for RAS Date: Mon, 11 Dec 1995 19:03:02 -0500 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Between the dial-back security, which presumably be done on a fixed number basis, and the authentication requirements of NT itself, why are you trying to do any additional security? Are you trying to limit access to specific machines within the network? If all the machines, internal and external, are Windows NT, then you can encrypt everything, passwords and data, end to end, with RAS. Where do you see the failing in the NT RAS security? Cheers, Russ Cooper, Senior Internet Integration Engineer SHL/Computer Innovations (now an MCI company) RCooper@the-wire.com or RWCooper@shl.com "where do you wanna go to get the money to go to where you wanna go today" From firewalls-owner Mon Dec 11 17:15:30 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA14444 for firewalls-outgoing; Mon, 11 Dec 1995 15:46:08 -0800 (PST) Received: from mesquite.bmc.com (mesquite.bmc.com [198.147.191.116]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id PAA14427 for ; Mon, 11 Dec 1995 15:46:01 -0800 (PST) Received: from ripken.bmc.com.bmc.com (ripken.bmc.com) by mesquite.bmc.com with SMTP (1.37.109.16/16.2) id AA268045455; Mon, 11 Dec 1995 17:44:15 -0600 Received: by ripken.bmc.com.bmc.com (5.x/SMI-SVR4) id AA00472; Mon, 11 Dec 1995 17:45:13 -0600 From: cbriese@ripken.bmc.com (Chuck Briese) Message-Id: <9512111745.ZM470@ripken.bmc.com> Date: Mon, 11 Dec 1995 17:45:12 -0600 In-Reply-To: sgcccdc@citec.qld.gov.au (Colin Campbell) "Re: modems and accessing the internal network" (Dec 12, 9:21) References: <9512112321.AA07808@citecub.citec.qld.gov.au> X-Mailer: Z-Mail (3.2.0 06sep94) To: sgcccdc@citec.qld.gov.au (Colin Campbell) Subject: Re: modems and accessing the internal network Cc: firewallS@GreatCircle.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Dec 12, 9:21, Colin Campbell wrote: > Subject: Re: modems and accessing the internal network > > If you use a terminal server and TACACS+ to authenticate and control the > users, you can set access lists that specify what commands and destinations > a user can access. That way you can control who goes where. Of course that > means you have to secure the boxes that they connect to from the terminal > server but at least it's a start at limiting the accessibility of the > internal network. >-- End of excerpt from Colin Campbell Well, there's the key. I have to overhaul the security of all of my internal boxes, and even going as far as adding firewalls between portions of my internal network. This should probably happen anyway; I'm just not looking forward to it. And, because of users and management's perceived needs, I can't go with a "that which is expressedly permitted" approach along the ISDN link/firewall; I have to go with a "that which is not prohibited" approach. Then I probably need to set up some sort of authenticated telnet and ftp proxies. Finally, I really should encrypt the traffic between my ISDN server and the clients. The latter is the toughest part, because I'll have Windows, OS/2, 95, NT and various Unix clients coming in via ISDN. Does anyone have any suggestions? Frank? -- Chuck Briese, striving for zero defects in an inherently defective world BMC Software, Inc., 2101 City West Blvd., Houston 77042 (713) 918-1216 From firewalls-owner Mon Dec 11 17:22:02 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id QAA16444 for firewalls-outgoing; Mon, 11 Dec 1995 16:17:29 -0800 (PST) Received: from mail.Clark.Net (mail.clark.net [168.143.0.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id QAA16438 for ; Mon, 11 Dec 1995 16:17:22 -0800 (PST) Received: from clark.net (clark.net [168.143.0.7]) by mail.Clark.Net (8.7.3/8.6.5) with ESMTP id TAA02145; Mon, 11 Dec 1995 19:16:41 -0500 (EST) Received: (from proberts@localhost) by clark.net (8.7.1/8.7.1) id TAA29934; Mon, 11 Dec 1995 19:16:39 -0500 (EST) Date: Mon, 11 Dec 1995 19:16:36 -0500 (EST) From: "Paul D. Robertson" To: Russ Cooper cc: "'malcolm melville 071 510 8472'" , firewalls Subject: RE: MS password cracker In-Reply-To: <01BAC7FA.4B57B2E0@rcooper.the-wire.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk On Mon, 11 Dec 1995, Russ Cooper wrote: > then Paul D. Robertson postulated ..."This is the first I've heard of this > -- although I'm not terribly surprised, given that it's such an obvious > point of attack on WFW machines (and so can be used as a launch point for > more serious attacks)."... > > So Paul, put up or shut up, have you ever been able to crack a Windows for > Workgroups .PWL using anything other than brute force? Or is this just > another example of an unsubstantiated claim? > Kenneth Smith made that statement, not I. I don't do unsubstantiated claims without calling them such. Check your facts, and watch the attributions next time before you attempt to foam off at the mouth. Paul. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts@clark.net which may have no basis whatsoever in fact." PSB#9280 From firewalls-owner Mon Dec 11 17:27:34 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id PAA15223 for firewalls-outgoing; Mon, 11 Dec 1995 15:57:39 -0800 (PST) Received: from psyche.the-wire.com (psyche.the-wire.com [198.53.192.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id PAA15209 for ; Mon, 11 Dec 1995 15:57:33 -0800 (PST) Received: from rcooper.the-wire.com (rcooper.the-wire.com [198.53.159.74]) by psyche.the-wire.com (8.6.10/8.6.9) with SMTP id SAA00330; Mon, 11 Dec 1995 18:56:31 -0500 Received: by rcooper.the-wire.com with Microsoft Mail id <01BAC7FA.4B57B2E0@rcooper.the-wire.com>; Mon, 11 Dec 1995 18:55:52 -0500 Message-ID: <01BAC7FA.4B57B2E0@rcooper.the-wire.com> From: Russ Cooper To: "'malcolm melville 071 510 8472'" , "'proberts@clark.net'" Cc: firewalls Subject: RE: MS password cracker Date: Mon, 11 Dec 1995 18:55:41 -0500 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Malcolm Melville mumbled ..."Hmm.. I see no solution for WfW but I guess that is as expected. Thanks for the page reference."... So far as anyone has been able to determine, the RC4 encryption algorithm problem has not shown up in tests on Windows for Workgroup .PWL files. Windows NT does not use password caching in the same way, so it is unaffected. then Paul D. Robertson postulated ..."This is the first I've heard of this -- although I'm not terribly surprised, given that it's such an obvious point of attack on WFW machines (and so can be used as a launch point for more serious attacks)."... So Paul, put up or shut up, have you ever been able to crack a Windows for Workgroups .PWL using anything other than brute force? Or is this just another example of an unsubstantiated claim? Cheers, Russ Cooper, Senior Internet Integration Engineer SHL/Computer Innovations (now an MCI company) RCooper@the-wire.com or RWCooper@shl.com "where do you wanna go to get the money to go to where you wanna go today" From firewalls-owner Mon Dec 11 18:51:52 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id RAA21793 for firewalls-outgoing; Mon, 11 Dec 1995 17:55:05 -0800 (PST) Received: from solarnum.itd.uts.edu.au (solarnum.itd.uts.EDU.AU [138.25.16.3]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id RAA21784 for ; Mon, 11 Dec 1995 17:54:44 -0800 (PST) Received: from lordmuck.itd.uts.edu.au (matt@lordmuck.itd.uts.EDU.AU [138.25.32.20]) by solarnum.itd.uts.edu.au (8.7.1/8.7.1/uts) with ESMTP id MAA10629; Tue, 12 Dec 1995 12:51:12 +1100 (EST) Received: (from matt@localhost) by lordmuck.itd.uts.edu.au (8.7.2/8.7.2/Jas) id MAA10985; Tue, 12 Dec 1995 12:55:49 +1100 (EST) From: Jas (Matthew K) Message-Id: <199512120155.MAA10985@lordmuck.itd.uts.edu.au> Subject: Re: MS password cracker To: firewalls@greatcircle.com (Firewalls Mailing List) Date: Tue, 12 Dec 1995 12:55:49 +1100 (EST) Cc: rcooper@the-wire.com In-Reply-To: from "Paul D. Robertson" at Dec 11, 95 07:16:36 pm X-Gcb: -----BEGIN GEEK CODE BLOCK----- X-Gcb: Version: 3.1 X-Gcb: GAT/M/CS d-(++) s++:-- a-(?) C+++$ UVS++++$ P+++ L+ E++ W++ N++ X-Gcb: !o K+ w--- O+ M+ V-- PS+ PE+ Y+ PGP++ t+ 5+ X++ R tv- b++ DI+ X-Gcb: D+ e h- r !y X-Gcb: ------END GEEK CODE BLOCK------ X-Ph: ph: +61 2 330 1390 fax: +61 2 330 1999 home: +61 2 9929 0717 X-Pager: +61 2 214 1111 #849482 or 849482@pager.link.com.au X-Pgp-Finger: pub 2048/27FB4AE1 1995/09/30 Jas (Matthew K) X-Pgp-Finger: Key fingerprint = 3A1EEDBE7A6D498D E7953FB40A21A6C8 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: firewalls-owner@GreatCircle.COM Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Paul D. Robertson wrote this... > On Mon, 11 Dec 1995, Russ Cooper wrote: >> So Paul, put up or shut up, have you ever been able to crack a Windows for >> Workgroups .PWL using anything other than brute force? Or is this just >> another example of an unsubstantiated claim? abviously russ doesnt watch either bugtraq or cypherpunks (pity, theres plenty of good stuff there). both lists carried source code that will crack a windows .PWL file in less than a second on most 486 machines.. > Kenneth Smith made that statement, not I. I don't do > unsubstantiated claims without calling them such. Check your facts, > and watch the attributions next time before you attempt to foam off > at the mouth. always good advice :) Matt - -- #!/bin/sh echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D3F204445524F42snlbxq'|dc;exit Matthew Keenan Systems Programmer Information Technology Division University of Technology Sydney Australia It's nice to be in a position where people apologize because they assume there's humor in your work, based on past experience, but they're not sure where it is. -- Rob Pike -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQEVAwUBMMzgpYSVUk8n+0rhAQELxQf/YaV7XNKk0ui5I60iWn13jW6Y6SHZ+cpP RoB40mbYYckfvmTXoUoNF3IeIRj3XyfZGaf9udEpARK77ABBcxpun9epyBnvPnp0 fEQYH8KTtrK5zI9l3OxSUvgq6xaTrcqbvhfeBJWn4haTZyh2VdGvbpa+on51v/qT ajkkoItegiF51aarevy/H9XfcRnxBpGn2IJx91W456w2n4DG0PL3OWMCwz32fzY3 TkfZq6X3RKhr77TG3CspEGqpUWmmgXtslGKCT2k/I5oyKYSvsTVyZslAoYdzFH2c KrINFhFp8ykqIGLQvaBNWsC0o6x0+OmWr2ov6hPLnzrzuvmGDQ8GlA== =X6qb -----END PGP SIGNATURE----- From firewalls-owner Mon Dec 11 19:31:28 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id TAA24583 for firewalls-outgoing; Mon, 11 Dec 1995 19:02:47 -0800 (PST) Received: from lint.cisco.com (lint.cisco.com [171.68.235.77]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id TAA24564 for ; Mon, 11 Dec 1995 19:02:42 -0800 (PST) Received: from pferguso-pc.cisco.com (c2robo5.cisco.com [171.68.13.31]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id TAA00165; Mon, 11 Dec 1995 19:01:42 -0800 Message-Id: <199512120301.TAA00165@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Dec 1995 22:01:58 -0500 To: Eric Vanuska From: Paul Ferguson Subject: Re: modems and accessing the internal network Cc: Jon Doran , firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk At 09:02 AM 12/11/95 -0800, Eric Vanuska wrote: >How are internal modems less susceptible to compromise than external >modems? It seems to me that using authentication can be done just as easily >for modems outside the firewall, as for those inside. As far as sniffing >goes, which is more damaging, sniffing an external network, versus the internal >network, would depend on what you're letting through your firewall and other >traffic patterns. > This is an issue of trust, and if you are not going to extend trust *somewhere*, you'll never meet you're goal of having a functional network. The original question posed, I believe, was one which asked something similar to 'external v. internal' modem access, and I responded that interal was preferable, with caveats. The caveats are that it *must* be authenticated access. This can be done effectively with one-time token cards, and once access is granted, the trust is extended. Let's take sniffing out of this argument; regardless of where it is done, it is a Bad Thing. - paul -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso@cisco.com c i s c o S y s t e m s From firewalls-owner Mon Dec 11 19:52:03 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id TAA24639 for firewalls-outgoing; Mon, 11 Dec 1995 19:04:15 -0800 (PST) Received: from gauntlet-1.trusted.com (gauntlet-1.trusted.com [204.254.155.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id TAA24625 for ; Mon, 11 Dec 1995 19:04:10 -0800 (PST) Received: by gauntlet-1.trusted.com; id WAA20353; Mon, 11 Dec 1995 22:07:59 -0500 Message-Id: <199512120307.WAA20353@gauntlet-1.trusted.com> Received: from vanidor.trusted.com(204.254.155.8) by gauntlet-1.trusted.com via smap (T3.1) id xmaa20342; Mon, 11 Dec 95 22:07:30 -0500 X-Sender: avolio@gauntlet-1.trusted.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Dec 1995 22:01:17 -0500 To: root , firewalls@GreatCircle.COM From: Frederick M Avolio Subject: Re: TIS FWTK Help Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Did you read the readme files? If so, why are you posting here and not to the FWTK specific mailing lists? There is important information in the README and other files (like LICENSE) so I am concerned you've missed something else important. Fred At 12:15 AM 12/11/95 -0500, root wrote: > > I've installed TIS FWTK and I have two problems that I haven't >solved yet: > > 1) I need examples of the httpd-gw, plug-gw as I haven't been able > to figure out how to use these effectively. Me thinks I need a > brain upgrade... > > 2) I'm having problems with smap/smapd/sendmail. > > The layout is as follows: > > --internet--[Livingston Firewall Router]----[bastion] > + > +--[internal server] > > The bastion runs httpd, ftpd, and the proxies. > > I'd like to run sendmail on the internal server, with SMAP/SMAPD on >the bastion. Currently, if I send mail to a user on the bastion, he gets >it. If I send mail to user directly on the internal server or a user >NBOT on the bastion, the mail bounes after a few days. > > Clues, tips, good advice cheerfully accepted. > > Flames directed to /dev/bill_gates ;-) > >========= << raj >> == http://www.brainlink.com/~frostbit/ ============== > frostbit@brainlink.com > SYSADMIN: BrainLINK System (718) 805-8868 // http://www.brainlink.com > GCS d++ H-- s+:+ !g p2 !au a- w+ v-* C++++ US++++ L++ P+++ E- N+ W--- > M-- po Y+ t-- 5+++ j++ tv b+++ e++ u+ h++ f+ r++ n+ y+ >============================================================================ > > --- TIS's Trusted Network Systems division has moved. New e-mail is avolio@trusted.com (although avolio@tis.com will work) New voice number is 301-527-9500 x115 New fax number is 301-527-0482 New address is TIS, 2277 Research Boulevard, Rockville, MD 20850 From firewalls-owner Mon Dec 11 20:22:03 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id TAA26814 for firewalls-outgoing; Mon, 11 Dec 1995 19:54:14 -0800 (PST) Received: from odin.community.net (odin.community.net [140.174.119.10]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id TAA26789 for ; Mon, 11 Dec 1995 19:53:49 -0800 (PST) Received: from [140.174.226.111] (n111.coco.community.net [140.174.226.111]) by odin.community.net with SMTP id TAA11903 for ; Mon, 11 Dec 1995 19:52:38 -0800 Date: Mon, 11 Dec 1995 19:52:38 -0800 Message-Id: <199512120352.TAA11903@odin.community.net> Subject: RE: modems and accessing the internal network From: Bill Husler To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk >I personally consider modems to be in hostile territory and therefore >go on the outside of the firewall. then, if compromised, they have >another level to get through. Even if authorized, and they >somehow get through both the modem and the firewall, at least I have >audit trails from the firewall, sicne I audit everyone/everything, >trusted or not. > >Modems are too easily attacked, protected or not, and if the >connection is on the outside, then all the better. > We have our Internet Firewall set for NO INBOUND traffic. For this reason, I would not put the modem pool on the public side of that Firewall. Being able to say absolutely none is a very powerful thing (compared with well, sometimes they can come in). Although, there is nothing keeping you from having a second firewall for the Modem Pool. Bill From firewalls-owner Mon Dec 11 20:52:05 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA29415 for firewalls-outgoing; Mon, 11 Dec 1995 20:35:43 -0800 (PST) Received: from garrison.garrison.com. (garrison.garrison.com [199.1.78.14]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id UAA29404 for ; Mon, 11 Dec 1995 20:35:36 -0800 (PST) Received: by garrison.garrison.com. (4.1/SMI-4.1) id AA00996; Mon, 11 Dec 95 22:33:02 CST Date: Mon, 11 Dec 95 22:33:02 CST From: jeromie@garrison.garrison.com (Jeromie Jackson) Message-Id: <9512120433.AA00996@garrison.garrison.com.> To: firewalls@greatcircle.com, mclelcl@onto.network.com Subject: RE: X.25 Firewall Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > Check out Network Systems BorderGuard and Security Router. WWW.NETWORK.COM > > Message: > What firewalls are there that can handle X.25, SNA and TCP/IP. > Remember that NSC's products are filtering products that have the ability to encrypt traffic. They have have the inherent weakness of Identification and NO authentication, thus if you have to speak to both the public world, and your business associates, their solution only solves 1/2 of the problem Jeromie Jackson Garrison Associates jeromie@garrison.com From firewalls-owner Mon Dec 11 21:22:03 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA00283 for firewalls-outgoing; Mon, 11 Dec 1995 20:49:15 -0800 (PST) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id UAA00267 for ; Mon, 11 Dec 1995 20:49:07 -0800 (PST) Message-Id: <199512120449.UAA00267@miles.greatcircle.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA175553680; Tue, 12 Dec 1995 15:48:00 +1100 From: Darren Reed Subject: Re: Timing Attack To: jim@SmallWorks.COM (Jim Thompson) Date: Tue, 12 Dec 1995 15:48:00 +1100 (EDT) Cc: PADGETT@hobbes.orl.mmc.com, firewalls@GreatCircle.COM In-Reply-To: <9512111926.AA18488@hosaka.smallworks.com> from "Jim Thompson" at Dec 11, 95 01:26:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk In some mail from Jim Thompson, sie said: [...] > >However, it seems to require not only physical access to the machine > >executing the key manipulations but also the ability to determine when > >each successive bit of the calculation is complete. In that case, why not > >just read the key from the registers ? I do not see how such information > >could be extracted from a network connection. > > Then you should re-read the paper. If you can watch the cryptodata > flying by on the network, and measure how long the responses take, > you can break the key. > > This is what is so disturbing about the paper. Does this advocate putting sleep() for a pseudo-random amount of time in crypto code ? (sleep() would be several orders of magnitude larger than the crypto stuff took). Maybe we should just ask Microsoft to write crypto algorithms so they turn out bloated and slow anyway ? ;-) darren From firewalls-owner Mon Dec 11 21:52:02 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id UAA29681 for firewalls-outgoing; Mon, 11 Dec 1995 20:40:27 -0800 (PST) Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id UAA29675 for ; Mon, 11 Dec 1995 20:40:23 -0800 (PST) Received: from gateway.deere.com by relay7.UU.NET with SMTP id QQztta14675; Mon, 11 Dec 1995 23:39:48 -0500 (EST) Received: by gateway.deere.com; id WAA29398; Mon, 11 Dec 1995 22:39:42 -0600 Received: from deere.com(192.43.1.3) by gateway.deere.com via smap (g3.0.1) id xma029384; Mon, 11 Dec 95 22:39:34 -0600 Received: from TCP30.DX.DEERE.COM (tcp30-50.dx.deere.com) by deere.dx.deere.com (4.1/SMI-4.0) id AA00654; Mon, 11 Dec 95 22:39:35 CST Received: by TCP30.DX.DEERE.COM (Soft*Switch Central V4L380P6) id 893937220095345FDACDXC01; 11 Dec 1995 22:37:22 GMT Message-Id: Date: 11 Dec 1995 22:37:22 GMT From: "Postmaster" Subject: DISTRIBUTION STATUS To: Firewalls@GREATCIRCLE.COM Comment: MEMO 12.11.95 22.37 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk SAUTOIN1.FIREWALL DISTRIBUTION STATUS INFORMATION 12/11/95 22: 37:00 ======================================================================= DISTRIBUTION ID: SAUTOIN1.FIREWALL.1843 SUBJECT : Firewalls-Digest V4 #705 DOCUMENT NAME : %%DOCNAME DATE SENT : 12/11/95 TIME SENT: 22:12:00 ======================================================================= YOUR MAIL WAS NOT DELIVERED FOR THE FOLLOWING REASON: SNADS STATUS : 000F X.400 CODE : %%DIAGCODE INFORMATION : %%SUPPLINFO EXPLANATION : SNADS SYSTEM ERROR ======================================================================= RECIPIENT : DACRXL01.OUTX187 LAST NAME : RATH FIRST NAME : JOHN MIDDLE INITIAL : INITIALS : NATIVE NAME : COUNTRY : US ADMD : TELEMAIL PRMD : TRT400 ORGANIZATION : JOHN DEERE ORG UNIT 1 : DACRXL01 ORG UNIT 2 : ORG UNIT 3 : ORG UNIT 4 : DDA : ID!OUTX187 TITLE : DESKTOP SUPPORT DESCRIPTION : CUSTOMER SUPPORT (TEAM TECH) USERDATA : T 426:DUBUQUE WORKS TELEPHONE : 3015123 From firewalls-owner Mon Dec 11 21:54:25 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA01190 for firewalls-outgoing; Mon, 11 Dec 1995 21:05:15 -0800 (PST) Received: from denver.ssds.com (denver.ssds.com [134.127.16.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id VAA01185 for ; Mon, 11 Dec 1995 21:05:11 -0800 (PST) Received: from freke.ssds.com (rem_den29.ssds.com [134.127.122.29]) by denver.ssds.com (8.6.9/8.6.9.SSDSnet-hub) with SMTP id WAA22806; Mon, 11 Dec 1995 22:04:30 -0700 Message-Id: <2.2b8.32.19951212050207.006ab3d8@denver.ssds.com> X-Sender: cds@denver.ssds.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2b8 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Dec 1995 23:02:07 -0600 To: jon@ctasim.com (Jon Doran) From: "Chris Liljenstolpe (Swanson) - SSDS" Subject: Re: modems and accessing the internal network Cc: firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Greetings, Actually, I like putting it on a side-network off of the firewall systems. It is therefore protected from the Internet, but are also required to pass through the firewall to access the internal network. If this can not be done, then they should be put behind their own "firewall". Regards, -=Chris At 15:12 95/12/10 -0700, the sage, Jon Doran, uttered these words: (>I would like to hear everyone's comments on modem pool placement. Brent (>and Elizabeth suggest in their book to place them on the internal network (>and protect them really well. (> (>Hmm, does anyone else have a problem with this? To me the purpose of the (>firewall is to protect the internal network by providing a clear separation (>between the internal and external networks. I really don't like the idea (>of allowing an end-run around the Bastion hosts. (> (>I also don't care if J. Random Hacker dials in or telnets in. Authentication (>makes me feel better, and I'd like the same treatment for dial-in users as (>for telnet users. I'd like dial-in users to be authenticated via authsrv (>and allowed to connect to the internal network only. J Random Hacker then (>needs to compromise the authentication daemon, which would let him/her (>ruin all of your days as surely as if he/she were logged in locally. (> (>I haven't given serious thought to this, but something like a dial-in (>account (equivalent to dial-in password) with telnet as a shell (on a machine (>without the outbound proxy, so packet filters could kill outbound tn traffic) (>might work. The caller would need to authenticate before going anywhere (>(I hope). (> (>Can anything like this be done fairly easily, without compromising security? (>If not, what does everyone else do? (> (>Jon Doran (>jon@ctasim.com (>----------------------------------------------------------------- (> (>Jon Doran (>CTA Simulation Systems, LLC (>7315 E. Orchard Rd, Suite 100 (>Greenwood Village, CO 80111 (> (>(303) 889-1270 (>jon@ctasim.com (> (> (> -- ( ( | ( Chris Liljenstolpe ) ) (| ), inc. SSDS, Inc; 8400 Normandale Lake Blvd.; Suite 993 business driven Bloomington, MN 55437; technology solutions TEL 612.921.2392 FAX 612.921.2395 Um Yah Yah! From firewalls-owner Mon Dec 11 22:22:03 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id VAA03338 for firewalls-outgoing; Mon, 11 Dec 1995 21:58:34 -0800 (PST) Received: from eden-valley (eden-valley.aaii.oz.AU [192.35.59.242]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id VAA03333 for ; Mon, 11 Dec 1995 21:58:22 -0800 (PST) Received: from alamein (alamein.aaii.oz.AU) by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA14634; Tue, 12 Dec 1995 16:57:45 +1100 Received: from localhost by alamein (8.6.8.1/8.6.6) with SMTP id QAA25238; Tue, 12 Dec 1995 16:57:44 +1100 Message-Id: <199512120557.QAA25238@alamein> X-Authentication-Warning: alamein: anthony owned process doing -bs X-Authentication-Warning: alamein: Host localhost didn't use HELO protocol To: "Mark Horn [ Net Ops ]" Cc: firewalls@greatcircle.com From: anthony baxter Reply-To: anthony.baxter@aaii.oz.au Subject: Re: proxied SSL? In-Reply-To: Message from "Mark Horn [ Net Ops ]" of 1995-Dec-11 16:15:52, <199512112115.QAA05754@funws302.capmark.funb.com> Date: Tue, 12 Dec 1995 16:57:42 +1100 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > [ how can I proxy SSL through a firewall? ] You could use a socksified CERN httpd, with the patches from Ari Luotonen to add SSL support. Or you could roll your own, using either SSLREF from netscape, or if you have export problems with this, use SSLeay, from ftp.bond.edu.au. Anthony From firewalls-owner Mon Dec 11 22:52:03 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id WAA04433 for firewalls-outgoing; Mon, 11 Dec 1995 22:30:39 -0800 (PST) Received: from hosaka.smallworks.com (hosaka.SmallWorks.COM [192.207.126.1]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id WAA04428 for ; Mon, 11 Dec 1995 22:30:35 -0800 (PST) Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA21878; Tue, 12 Dec 1995 00:26:15 -0600 Date: Tue, 12 Dec 1995 00:26:15 -0600 From: jim@SmallWorks.COM (Jim Thompson) Message-Id: <9512120626.AA21878@hosaka.smallworks.com> To: avalon@coombs.anu.edu.au Subject: Re: Timing Attack Cc: PADGETT@hobbes.orl.mmc.com, firewalls@GreatCircle.COM Sender: firewalls-owner@GreatCircle.COM Precedence: bulk I'm sure that I never advocated putting 'sleep()' in any crypto code. (I'm not quite that dense, thanks.) Jim From firewalls-owner Tue Dec 12 01:22:03 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id BAA08629 for firewalls-outgoing; Tue, 12 Dec 1995 01:04:38 -0800 (PST) Received: from SanFrancisco01.POP.InterNex.Net (SanFrancisco01.POP.InterNex.Net [205.158.3.50]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with ESMTP id BAA08624 for ; Tue, 12 Dec 1995 01:04:35 -0800 (PST) Received: from Anthros.Com ([205.158.235.130]) by SanFrancisco01.POP.InterNex.Net (post.office MTA v1.7 ID# 0-11028) with SMTP id AAA15327 for ; Tue, 12 Dec 1995 01:04:46 -0800 Received: from phoebe.Anthros.Com by Anthros.Com (5.0/SMI-SVR4) id AA14162; Tue, 12 Dec 1995 01:02:21 -0800 Received: by phoebe.Anthros.Com (5.x/SMI-SVR4) id AA05151; Tue, 12 Dec 1995 00:59:42 -0800 Date: Tue, 12 Dec 1995 00:59:42 -0800 From: daemeonr@Anthros.Com@Anthros.Com Message-Id: <9512120859.AA05151@phoebe.Anthros.Com> To: firewalls@greatcircle.com Subject: Re: Access to Internal Databases X-Sun-Charset: US-ASCII Sender: firewalls-owner@GreatCircle.COM Precedence: bulk (1) try to use stored procs and an intermediate database (which is behind your firewall) (2) Allow access from the intermediate db to corp db's ONLY via stored proc (3) If in a Sybase environment, if you need access to other networked services (e.g. for credit card auth), use an Open Server. If in Oracle, too bad, you have a lot of bad code to write. If Informix, their Open Gateway (I believe that is the product name) works similarly. Basically, you are trying to restrict the *view* that a bad guy could have. Oh, by the way, be carefull to check the error (return) codes. I have a client that failed to do so with some interesting results. Daemeon => From firewalls-owner@GreatCircle.COM Fri Dec 8 18:59 PST 1995 => X-Authentication-Warning: NYXGATE1.btco.com: mailer set sender to using -f => To: firewalls@greatcircle.com => From: Guru Sundararaman => Subject: Access to Internal Databases from External Web Server => Date: Fri, 08 Dec 1995 13:43:38 -0500 => Organization: Bankers Trust Company => Nntp-Posting-Host: nycsew0068.btco.com => Mime-Version: 1.0 => Content-Transfer-Encoding: 7bit => Sender: firewalls-owner@GreatCircle.COM => Content-Type: text/plain; charset="us-ascii"; conversions="7bit" => => Is there a generally accepted model on how CGI programs on an => external Web server (sitting on the external segment of a => firewall) can securely access internal databases thro' the => firewall? => => I've dug thro' the mailing list archives and haven't seen any => resolution on this. => => Thanks, => -Guru => gurus@btco.com From firewalls-owner Tue Dec 12 02:39:58 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA10561 for firewalls-outgoing; Tue, 12 Dec 1995 02:18:12 -0800 (PST) Received: from ritig1.rit.reuters.com (ritig1.rit.reuters.com [199.171.195.11]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id CAA10555 for ; Tue, 12 Dec 1995 02:18:07 -0800 (PST) Received: from ritig4.rit.reuters.com by ritig1.rit.reuters.com; (5.65v3.2/1.1.8.2/14Sep94-0947PM) id AA17119; Tue, 12 Dec 1995 05:18:57 -0500 Received: from mr.rit.reuters.com by RITIG4.RIT.REUTERS.COM (PMDF V4.3-10 #7805) id <01HYPIED2XCG002SRI@RITIG4.RIT.REUTERS.COM>; Tue, 12 Dec 1995 05:17:39 -0500 (EST) Received: with PMDF-MR; Tue, 12 Dec 1995 10:15:09 EST Mr-Received: by mta REC.MUAS; Relayed; Tue, 12 Dec 1995 10:15:09 -0500 Mr-Received: by mta RE5; Relayed; Tue, 12 Dec 1995 10:15:12 -0500 Mr-Received: by mta RITIG4; Relayed; Tue, 12 Dec 1995 10:17:35 -0500 Disclose-Recipients: prohibited Date: Tue, 12 Dec 1995 10:15:09 -0500 (EST) From: malcolm melville 071 510 8472 Subject: Re: MS password cracker In-Reply-To: <01BAC7FA.4B57B2E0@rcooper.the-wire.com> To: firewalls Cc: firewalls Message-Id: <3709151012121995/A67032/RE5/119C628F0800*@MHS> Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Importance: normal Sensitivity: Company-Confidential Ua-Content-Id: 119C628F0800 X400-Mts-Identifier: [;3709151012121995/A67032/RE5] Hop-Count: 2 Sender: firewalls-owner@GreatCircle.COM Precedence: bulk -> Malcolm Melville mumbled ..."Hmm.. I see no solution for WfW but I guess -> that is as expected. Thanks for the page reference."... -> -> So far as anyone has been able to determine, the RC4 encryption algorithm -> problem has not shown up in tests on Windows for Workgroup .PWL files. -> Windows NT does not use password caching in the same way, so it is -> unaffected. -> -> then Paul D. Robertson postulated ..."This is the first I've heard of this -> -- although I'm not terribly surprised, given that it's such an obvious -> point of attack on WFW machines (and so can be used as a launch point for -> more serious attacks)."... -> -> So Paul, put up or shut up, have you ever been able to crack a Windows for -> Workgroups .PWL using anything other than brute force? Or is this just -> another example of an unsubstantiated claim? I have to admit to running the same code against WfW .PWL files and retrieving share passwords, are you saying this was a fluke? regards malcolm From firewalls-owner Tue Dec 12 03:22:05 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id DAA12013 for firewalls-outgoing; Tue, 12 Dec 1995 03:19:15 -0800 (PST) Received: from neon.cypronet.com (neon.cypronet.com [205.233.90.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id DAA12008 for ; Tue, 12 Dec 1995 03:19:12 -0800 (PST) Received: from helium.cypronet.com (helium.cypronet.com [205.233.90.5]) by neon.cypronet.com (8.6.12/8.6.9) with SMTP id FAA07556 for ; Tue, 12 Dec 1995 05:17:15 -0700 Date: Tue, 12 Dec 1995 05:17:15 -0700 Message-Id: <199512121217.FAA07556@neon.cypronet.com> X-Sender: jan@mail.cypronet.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@greatcircle.com From: "Jan (Monk) Vandenbos" Subject: Denying DNS services Sender: firewalls-owner@GreatCircle.COM Precedence: bulk HI... I'm sorry if this is the wrong place to ask this question. Does anyone know how I can refuse access to my nameservers to certain sites? Ie: if my nameserver is foo.bar.com (named) (dns) can I reject x.x.x.x from access it, or using it to resolve? Thanks. ...Jan From firewalls-owner Tue Dec 12 03:52:02 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id CAA11788 for firewalls-outgoing; Tue, 12 Dec 1995 02:58:43 -0800 (PST) Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id CAA11783 for ; Tue, 12 Dec 1995 02:58:39 -0800 (PST) Received: from ilosrv.ilo.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA09972; Tue, 12 Dec 1995 02:54:29 -0800 Received: from ilofrs.ilo.dec.com by ilosrv.ilo.dec.com; (5.65/1.1.8.2/12Nov94-8.2MPM) id AA01475; Tue, 12 Dec 1995 10:54:24 GMT Received: by fwsrtr.fws.ilo.dec.com; (5.65/1.3/10May95) id AA31710; Tue, 12 Dec 1995 10:56:40 GMT Received: from localhost by philby.fws.ilo.dec.com; (5.65/1.1.8.2/31Aug95-8.2MPM) id AA09417; Tue, 12 Dec 1995 10:53:38 GMT Message-Id: <9512121053.AA09417@philby.fws.ilo.dec.com> To: firewalls@greatcircle.com Subject: Re: Timing Attacks In-Reply-To: Your message of "Mon, 11 Dec 1995 17:15:23 EST." <951211171523.2021f537@hobbes.orl.mmc.com> X-Mailer: exmh version 1.4.1 7/21/94 Date: Tue, 12 Dec 1995 10:53:31 +0000 From: "Frank O'Dwyer" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > Frank rites: > >From the description, it sounds like all you need some "better than > >random guess" at how long en/decryption takes. And that's certainly > >possible without physical access. For example, if you view a > >remote server as an en/decrypting 'black box' (among other things) > >then you can give it work to do, and observe the response time. > > Can see how that might be possible at the keyboard. Might be possible on > a remote terminal with a direct connection. Cannot see how it would work > on a packet based network (having enough trouble with a std deviation of > 188 usec against an average difference of 17 usec.), just too many random > factors involved. True--but NTP and such manage to overcome similar obstacles. It's certainly not obvious how it would be done, but I wouldn't write it off as impossible just yet. Cheers, Frank O'Dwyer From firewalls-owner Tue Dec 12 03:54:16 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id DAA11920 for firewalls-outgoing; Tue, 12 Dec 1995 03:09:41 -0800 (PST) Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id DAA11913 for ; Tue, 12 Dec 1995 03:09:37 -0800 (PST) Received: from ilosrv.ilo.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA14200; Tue, 12 Dec 1995 03:01:50 -0800 Received: from ilofrs.ilo.dec.com by ilosrv.ilo.dec.com; (5.65/1.1.8.2/12Nov94-8.2MPM) id AA01548; Tue, 12 Dec 1995 11:01:47 GMT Received: by fwsrtr.fws.ilo.dec.com; (5.65/1.3/10May95) id AA31758; Tue, 12 Dec 1995 11:04:03 GMT Received: from localhost by philby.fws.ilo.dec.com; (5.65/1.1.8.2/31Aug95-8.2MPM) id AA09432; Tue, 12 Dec 1995 11:01:01 GMT Message-Id: <9512121101.AA09432@philby.fws.ilo.dec.com> To: Darren Reed Cc: firewalls@greatcircle.com Subject: Re: Timing Attack In-Reply-To: Your message of "Tue, 12 Dec 1995 15:48:00 +1100." <199512120449.UAA00267@miles.greatcircle.com> X-Mailer: exmh version 1.4.1 7/21/94 Date: Tue, 12 Dec 1995 11:00:53 +0000 From: "Frank O'Dwyer" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk > In some mail from Jim Thompson, sie said: > [...] > > >However, it seems to require not only physical access to the machine > > >executing the key manipulations but also the ability to determine when > > >each successive bit of the calculation is complete. In that case, why not > > >just read the key from the registers ? I do not see how such information > > >could be extracted from a network connection. > > > > Then you should re-read the paper. If you can watch the cryptodata > > flying by on the network, and measure how long the responses take, > > you can break the key. > > > > This is what is so disturbing about the paper. > > Does this advocate putting sleep() for a pseudo-random amount of time > in crypto code ? (sleep() would be several orders of magnitude larger > than the crypto stuff took). No. If you do that, then it might still be possible to deduce something about the key by looking at the performance of _other_ processes on the same machine. What you might do is busy wait before returning from the crypto function until a certain amount of CPU time had been used--but even then you would possibly influence the performance of the system (e.g. the paging rate). That's the other thing that's very disturbing about the paper. If it _is_ a threat, it's a very hard hole to close. The author proposes use "blinding" techniques, but that doesn't help all the crypto that's deployed out there. Cheers, Frank O'Dwyer. From firewalls-owner Tue Dec 12 04:22:03 1995 Received: (majordom@localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id DAA12885 for firewalls-outgoing; Tue, 12 Dec 1995 03:54:16 -0800 (PST) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.2.45]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id DAA12739 for ; Tue, 12 Dec 1995 03:50:20 -0800 (PST) Received: from faui01.informatik.uni-erlangen.de (root@faui01.informatik.uni-erlangen.de [131.188.2.1]) by uni-erlangen.de with ESMTP id MAA15477 (8.6.12/7.4f-FAU); for ; Tue, 12 Dec 1995 12:45:54 +0100 Received: from edi (tnsturm@faui04e.informatik.uni-erlangen.de [131.188.63.14]) by cip.informatik.uni-erlangen.de with SMTP id MAA05702 (8.6.12/7.4f-FAU); for ; Tue, 12 Dec 1995 12:45:51 +0100 Message-ID: <30CD6B6E.3F1CE245@cip.informatik.uni-erlangen.de> Date: Tue, 12 Dec 1995 12:45:50 +0100 From: Torsten Sturm Organization: CSD, Univ. Erlangen-Nuernberg, Germany X-Mailer: Mozilla 2.0b3 (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: firewalls@greatcircle.com Subject: Re: MS password cracker: Source here for info Content-Type: multipart/mixed; boundary="---------------------------166556110311131501082010899621" Sender: firewalls-owner@GreatCircle.COM Precedence: bulk This is a multi-part message in MIME format. -----------------------------166556110311131501082010899621 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- InfoSec webpage : http://www.rrze.uni-erlangen.de/~unrzg3/security/security.html __________________________________________________________________ http://wwwcip.informatik.uni-erlangen.de/user/tnsturm/index.html -----------------------------166556110311131501082010899621 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from listserv.gmd.de (listserv.gmd.de [192.88.97.1]) by cip.informatik.uni-erlangen.de with ESMTP id AAA14187 (8.6.12/7.4f-FAU); for ; Thu, 7 Dec 1995 00:29:43 +0100 Received: from listserv.gmd.de by listserv.gmd.de (LSMTP for OpenVMS v1.0a) with SMTP id 8DBD21C2 ; Thu, 7 Dec 1995 0:29:37 +0100 Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8b) with spool id 50018 for BUGTRAQ@NETSPACE.ORG; Wed, 6 Dec 1995 09:31:57 -0500 Received: from netspace.org (netspace [128.148.157.6]) by netspace.org (8.7/8.6.12) with SMTP id JAA01725 for ; Wed, 6 Dec 1995 09:26:06 -0500 Approved-By: CHASIN@CRIMELAB.COM Received: from crimelab.com (crimelab.com [198.64.127.1]) by netspace.org (8.7/8.6.12) with ESMTP id WAA16210 for ; Tue, 5 Dec 1995 22:37:53 -0500 Received: from Networking.Stanford.EDU (networking.Stanford.EDU [36.53.0.155]) by crimelab.com (8.7.1/8.6.4) with SMTP id UAA21851 for ; Tue, 5 Dec 1995 20:25:50 -0700 (MST) Received: (from llurch@localhost) by Networking.Stanford.EDU (8.6.11/8.6.6) id TAA29964; Tue, 5 Dec 1995 19:37:54 -0800 X-PGP-key: finger llurch@mordor.stanford.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Rich Graves Message-ID: Date: Tue, 5 Dec 1995 19:37:50 -0800 Reply-To: Bugtraq List Sender: Bugtraq List From: Rich Graves Subject: Re: Cracked: WINDOWS.PWL [most services accessed by any version of Microsoft Windows] X-To: Bugtraq List To: Multiple recipients of list BUGTRAQ In-Reply-To: X-Mozilla-Status: 0011 -----BEGIN PGP SIGNED MESSAGE----- [Reply to BUGTRAQ, Bcc'd to a local list.] On Tue, 5 Dec 1995, Michael S. Fischer wrote: > I don't know if this is suitable for inclusion on Bugtraq, but it's quite > scary if the implications are as described... > > >---------- Forwarded message ---------- > >Date: Mon, 4 Dec 1995 19:06:12 +0100 > >From: Tatu Ylonen > >To: ssh@clinet.fi > >Subject: FWD from Frank Andrew Stevenson: Cracked: WINDOWS.PWL > > > >I am sorry to send noise to the list; this deals with Windows95 but is > >quite relevant to many Unix administrators as well. This is not > >related to ssh. The ssh list is not intended for this kind of stuff, > >so please don't do what I am doing now. > > > >Basically, you should be aware that if you ever mount disks from Unix > >machines to Windows95 machines, the passwords of the unix machine (or > >your other file servers) will be stored on the Windows machine's disk > >essentially in the plain, and any 10-year computer-literate kid with a > >little knowledge will be able to retrieve them in seconds if he gets > >access to client machine. [Quoted message, complete with source code, deleted. See sci.crypt or the cypherpunks archives.] Well, the Win95 SMB security bug was discussed here, so I think this is at least as relevant. Win95 (and Windows for Workgroups; this might also apply to NT) will indeed save passwords for Samba servers running on UNIX machines, NetWare servers on UNIXWare machines, and UNIX SLIP/PPP servers. It will save them in weakly encrypted .PWL files. According to article <4a2bij$ma6@wizard.uark.edu> in comp.security.misc, a decent machine can crack .PWL files in less than one second. Bugs have been reported (but not confirmed) that might under some circumstances cause Win95 to save .PWL files totally unencryted. Microsoft encourages developers to use the .PWL architecture, so other network operating systems and "security tools" are also likely to use the .PWL file, if not now, then in the future. I don't believe this applies to the current versions of PC/NFS or other Win95-enabled NFS clients; I would think that the TGV and B&WS guys would be smarter than that, but confirmation of this point would be appreciated. .PWL files for any user of the Win95 machine can be picked up by anyone with physical access to the machine, or by anyone with network access to the C:\WINDOWS directory on the machine. If the recently posted file sharing patches are not installed (and currently, they are only available for the US-English version of Win95, despite assurances from the Win95 product manager that international versions would be available over a week ago), and if file sharing for any subdirectory of the machine is enabled, then anyone within your firewall (if any) and with knowledge of even the Win95 machine's most restrictive sharing or administrator password (if any; passwordless guest access will work if it's enabled) can get read access to *any* directory starting from root, including C:\WINDOWS\*.PWL. The solution is to disable "password caching" entirely and to delete C:\WINDOWS\*.PWL on any machine that is not physically and network-secured. Ideally, one would disable the supposed "user profiles" feature of Win95 entirely, and present it as the totally insecure single-user client operating system it is, so as to avoid the risks associated with a false sense of security. To fix this for Windows for Workgroups, insert "passwordcaching=no" into the [NETWORK] section of SYSTEM.INI [Credit Jim Carlson]. To disable "password caching" on Win95, you could run PolEdit [Credit Don Edwards], but IMO this is a bad idea, because ways have been published to disable "Policies," which users might want to do for other reasons. The better alternative is to create the following undocumented Registry entry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\ Network\DisablePwdCaching This gets a binary value of 1 [Credit Malcolm G. Miles]. Of course you'd have to check from time to time to ensure that som