-------- From academic-firewalls-owner@net.tamu.edu Tue Jul 26 16:26:02 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id QAA12840 for academic-firewalls-a; Tue, 26 Jul 1994 16:26:00 -0500 Received: from posaune.tamu.edu (posaune [128.194.177.4]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id QAA12834 for ; Tue, 26 Jul 1994 16:25:57 -0500 Received: by posaune.tamu.edu (NX5.67d/NX3.0M) id AA00850; Tue, 26 Jul 94 16:22:43 -0500 Message-Id: <9407262122.AA00850@posaune.tamu.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) Date: Tue, 26 Jul 94 16:22:43 -0500 Precedence: bulk From: Dave Hess Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: digest? > is this available in digest format? We are currently putting together the machinery to provide one. It is in its test phase at the moment but should be ready in about a week. We'll post a note about it on the list. Dave - --- David K. Hess Network Analyst David-Hess@tamu.edu Computing and Information Services - Network Group (409) 845-0372 (work) Texas A&M University -------- From academic-firewalls-owner@net.tamu.edu Wed Jul 27 16:24:08 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id QAA01820 for academic-firewalls-a; Wed, 27 Jul 1994 16:18:36 -0500 Received: from localhost (d1s8027@localhost) by net.tamu.edu (8.6.7/8.6.7) with SMTP id QAA01813 for ; Wed, 27 Jul 1994 16:18:34 -0500 Message-ID: <1812.775343913@net.tamu.edu> Date: Wed, 27 Jul 1994 16:18:33 -0500 Precedence: bulk From: Douglas Lee Schales Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Other Universities... Let's try to kick things off... We're curious about what other Universities are doing/considering in regards to firewalling; items such as policies, procedures, activities, tools. Also, how the user community accepts restrictions created by a firewall would be of interest. Just in brief, here at Texas A&M, we use an in-house developed packet filter (in use for ~2 years), along with a system that monitors for possible intrusions. The main goal of the packet filter is to "hide" hosts on the network that contain well known vulnerabilities. We use a deny unless specifically allowed approach with the filter. In the environment here, there are a large number of machines which are administered by Professors & the grad student of the week. They usually have no idea that there machine has a '+' in hosts.equiv (or even what that means), or that passwordless accounts are a bad idea. The packet filter allows us to shield those hosts from the Internet, thus reducing the chances of the host being compromised, and then being used to compromise other hosts on campus. Doug. - -- Douglas Lee Schales Texas A&M University Doug.Schales@net.tamu.edu Computing & Information Services Networking Project -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 10:38:55 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id KAA12820 for academic-firewalls-j; Thu, 28 Jul 1994 10:38:39 -0500 Received: from ncar.UCAR.EDU (ncar.ucar.edu [192.52.106.6]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id KAA12781 for ; Thu, 28 Jul 1994 10:38:25 -0500 Message-Id: <199407281538.JAA00706@ncar.ucar.EDU> Received: by ncar.ucar.EDU (NCAR-local/ NCAR Central Post Office 03/11/93) id JAA00706; Thu, 28 Jul 1994 09:38:23 -0600 X-Mailer: ELM [version 2.3 PL11] Date: Thu, 28 Jul 94 9:38:22 MDT Precedence: bulk From: woods@ncar.UCAR.EDU (Greg Woods) Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Other Universities... > From: Douglas Lee Schales > > We're curious about what other Universities are doing/considering in > regards to firewalling Well, we aren't a university, but as a public research institution we do face some, but not all, of the problems that a typical university faces. We don't have to worry about 10,000 or so hackers on our internal net :-) but we do have a user base that is used to free and open access to the Internet, and indeed this is even crucial to our research mission. As a national supercomputer center we could not even function without being able to provide worldwide access to our computing facilities via the Internet. As such, much of the standard advice about firewalls has to be thrown out the window. We have less to lose than, say, AT&T (the point of view that Cheswick and Bellovin write from) but that doesn't mean we have NOTHING to lose. We don't really have any concerns about information leaking out; everything we do is intended for public consumption. But we do have to worry about systems being damaged or otherwise brought down which obviously would have a direct impact on productivity. But our situation does imply we can afford to take more risks than most of those who implement firewalls for a living. We are not as attractive a target as our corporate friends. > Also, how the user community accepts restrictions > created by a firewall would be of interest. This is going to be a tough one. We just finished convincing management that we need some kind of firewall. This was a much easier task now that the machine on which our division director reads his mail was broken into and was down for a day while the OS was re-installed :-) Nothing like a little personal experience to convince someone. We are now considering using packet filters to block almost all access into our network and make all accesses go through a couple of application gateway machines and use one-time passwords. I think for the interactive logins the user community will eventually accept this, but they often send things in via automated scripts that run in the middle of the night; they will be very upset at having this capability taken away from them. Unfortunately I really do not know any way we can protect ourselves against password sniffing without one-time passwords. The most secure application gateway in the world doesn't do any good if the bad guys can get hold of legitimate login names and passwords. - --Greg -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 10:51:54 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id KAA13081 for academic-firewalls-j; Thu, 28 Jul 1994 10:51:28 -0500 Received: from Bump.Stanford.EDU (Bump.Stanford.EDU [36.18.0.224]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id KAA13045; Thu, 28 Jul 1994 10:51:12 -0500 Received: (kjd@localhost) by Bump.Stanford.EDU (8.6.8/8.6.4) id IAA15301; Thu, 28 Jul 1994 08:51:10 -0700 Message-Id: <199407281551.IAA15301@Bump.Stanford.EDU> CC: academic-firewalls@net.tamu.edu In-reply-to: Douglas Lee Schales's message of Wed, 27 Jul 1994 16:18:33 -0500 <1812.775343913@net.tamu.edu> Date: Thu, 28 Jul 1994 08:51:10 -0700 Precedence: bulk From: Kenneth Duda Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Texas A&M network security >> Just in brief, here at Texas A&M, we use an in-house developed packet >> filter (in use for ~2 years), along with a system that monitors for >> possible intrusions. The main goal of the packet filter is to "hide" >> hosts on the network that contain well known vulnerabilities. We use >> a deny unless specifically allowed approach with the filter. I'm a member of the Distributed Systems Group at Stanford University. We're in the process of setting up a firewall to protect our machines. As part of this effort, we're attempting to develop a general security architecture and specific technologies suitable for use at a university. Doug, I have some questions about your physical setup. I assume your university network has one or more Internet connections connected to some sort of hub with building subnets hanging off. Where does the filter go in relationship to this setup? Outside a particular protected building? Between the university and the Internet as a whole? How many such filters do you have? How many hosts does a typical filter protect? I ask this set of questions because our group is unconvinced that a single firewall at each Internet connection (which seems to be the unquestioned architecture in the corporate community) is a good architecture for the academic community. I was wondering if you had experimented with alternatives. We are experimenting with alternatives where firewalls are distributed according to administrative boundaries within the university. This is inspired by the way physical security is organized within universities. I also have some questions about your filtering policy. Do you allow arbitrary packets out? UDP in? Protocols other than TCP or UDP? What TCP services do you allow in and out? I assume that if you want to protect students with + in hosts.equiv, you must filter out incoming rlogin, rsh, rcp, telnet, etc. connections. Do graduate students notice when they are unable to telnet to their workstations from the other side of the firewall? Can they dial into their workstations? How do you provide mail service while protecting their workstations from sendmail bugs and incorrect configurations? When they telnet out, are external X clients able to connect to their workstation's X server? And finally, some questions on larger issues involved in setting up an "academic firewall". Who are you trying to protect your machines from? I see probably four levels here: curious students in other departments, vandalous outsiders, outside research groups who want to steal your ideas, and well-funded foreign intelligence agencies. How does your protection strategy differ for the administrative arm of your organization (whose data is usually considered more sensitive than that of the academic arm)? And, finally, to what degree do you permit local administration of security systems? In otherwords, if a certain group decided it was willing to trade off less security for greater connectivity, would this be possible within your architecture? Thanks, Kenneth J. Duda http://www-dsg.stanford.edu/KennethDuda.html Stanford University Distributed Systems Group 415-723-9429 Building 460 / Stanford, CA 94305 p.s. I love the term "academic firewall". Our academic firewall takes a lot of notes and carefully thinks through the fundamental issues. And when it sees a really dangerous packet go by, it springs into action: it writes a paper! -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 11:03:42 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id LAA13411 for academic-firewalls-j; Thu, 28 Jul 1994 11:03:19 -0500 Received: from Bump.Stanford.EDU (Bump.Stanford.EDU [36.18.0.224]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id LAA13372 for ; Thu, 28 Jul 1994 11:02:59 -0500 Received: (kjd@localhost) by Bump.Stanford.EDU (8.6.8/8.6.4) id JAA26327; Thu, 28 Jul 1994 09:02:58 -0700 Message-Id: <199407281602.JAA26327@Bump.Stanford.EDU> In-reply-to: Greg Woods's message of Thu, 28 Jul 94 9:38:22 MDT <199407281538.JAA00706@ncar.ucar.EDU> Date: Thu, 28 Jul 1994 09:02:58 -0700 Precedence: bulk From: Kenneth Duda Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Securing a supercomputer site >> We are now considering >> using packet filters to block almost all access into our network and make >> all accesses go through a couple of application gateway machines and use >> one-time passwords. I think for the interactive logins the user community >> will eventually accept this, but they often send things in via automated >> scripts that run in the middle of the night; they will be very upset at >> having this capability taken away from them. Unfortunately I really do not >> know any way we can protect ourselves against password sniffing without >> one-time passwords. The most secure application gateway in the world >> doesn't do any good if the bad guys can get hold of legitimate login >> names and passwords. If you have a determined user community, it seems that single-use keys could backfire. Your users might keep lists of keys in local files, and have their automated scripts take the keys from the files. I'm sure this would amuse the hackers that break into their machines, and save them the trouble of setting up sniffers. It seems to me that if you have a set of users outside of the network you administer who frequently log in remotely, you need to decide either to trust their local net or not to trust it. If you do trust it, there are a variety of things you could do. For example, you could have them hack their router to encapsulate and DES-encrypt all IP, which you de-encapsulate and decrypt on your router; this would give you security with no change on their workstations or in their habits. A simpler solution using more readily-available technology would be Kerberos, although that requires minor client workstation configuration and some discipline on your users' part to keep from inadvertently revealing their passwords to sniffers. On the other hand, if you don't trust their local network, I see no airtight solutions. Single-use keys don't really quite work, even if your users don't put them in files, because a determined hacker could replace their remote login client, fool them into revealing their next key, and then use their key. Does anyone else have thoughts on protecting a network for which frequent remote login capability from static distant points on the Internet is a business need? Kenneth J. Duda http://www-dsg.stanford.edu/KennethDuda.html Stanford University Distributed Systems Group 415-723-9429 Building 460 / Stanford, CA 94305 -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 11:32:49 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id LAA13967 for academic-firewalls-j; Thu, 28 Jul 1994 11:32:27 -0500 Received: from ncar.UCAR.EDU (ncar.ucar.edu [192.52.106.6]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id LAA13930 for ; Thu, 28 Jul 1994 11:32:13 -0500 Message-Id: <199407281632.KAA04899@ncar.ucar.EDU> Received: by ncar.ucar.EDU (NCAR-local/ NCAR Central Post Office 03/11/93) id KAA04899; Thu, 28 Jul 1994 10:32:11 -0600 In-Reply-To: <199407281602.JAA26327@Bump.Stanford.EDU>; from "Kenneth Duda" at Jul 28, 94 9:02 am X-Mailer: ELM [version 2.3 PL11] Date: Thu, 28 Jul 94 10:32:10 MDT Precedence: bulk From: woods@ncar.UCAR.EDU (Greg Woods) Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Securing a supercomputer site > Your users might keep lists of keys in local files, > and have their automated scripts take the keys from the files. I'm > sure this would amuse the hackers that break into their machines, and > save them the trouble of setting up sniffers. This is not possible with the schemes we are considering. We're talking about the credit card sized devices that tell the user what the password is for this particular login attempt. Possession of the device is required, as is a PIN number, in order to be successfully authenticated. > It seems to me that if you have a set of users outside of the network > you administer who frequently log in remotely, you need to decide > either to trust their local net or not to trust it. The whole point is, we don't want to trust any remote hosts or networks. We've got users all over the WORLD on many different hosts and networks. We've got lots of places where there is only one user who accesses us; as such, solutions that require the cooperation of the remote system administrators (such as Kerberos and other methods of encrypting the session that require special software on the user's host at the remote end) are not very practical. However, one of your points is well taken; it may be that there are a few remote networks that we WOULD be willing to trust (such as, other supercomputer centers that we know have taken adequate security measures, that is to say, security measures at least as stringent as our own). In those cases we could allow unauthenticated (but closely monitored) access. But that isn't going to be a general solution for us, and it does bring up the more general issue of how to pass traffic from one "secure" net to another across an insecure connection between them. > because a determined hacker could > replace their remote login client, fool them into revealing their next > key, and then use their key. This is a point worth noting and I confess I hadn't thought about this before. But as you say, it does require a pretty determined hacker who is monitoring the user in real time. It's a risk, but I think it's a pretty SMALL risk (it might not be so small a risk for someone interested in protecting valuable information, however). It would also be detectable if we were monitoring closely enough. It could probably be made to look to the user as if it was just a typo or something; first login attempt gets rejected (and the hacker uses that key to log in), but in that case, assuming the user really did mean to log in, either the user's attempts would keep failing in which case we hope the problem would get reported (not much doubt of it with *our* users :-) or else we'd see the same user coming in twice almost simultaneously. Something to watch for! > Does anyone else have thoughts on protecting a network for which > frequent remote login capability from static distant points on the > Internet is a business need? One-time passwords are really the ONLY way, unless (as you mentioned) you are willing to trust the security of the remote network. In our case, I doubt very much that there is any way we can offer the access to our remote users that they need that can absolutely prevent breakins by a very knowledgeable and sufficiently determined hacker. The best we can do is make it hard for the "cookbook" hackers and make it likely that we would detect any breakin that DID occur. - --Greg -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 12:56:45 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id MAA14695 for academic-firewalls-j; Thu, 28 Jul 1994 12:56:20 -0500 Received: from whistler.sfu.ca (root@whistler.sfu.ca [142.58.103.1]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id MAA14658 for ; Thu, 28 Jul 1994 12:56:05 -0500 Received: from fraser.sfu.ca (vanepp@fraser.sfu.ca [128.189.32.21]) by whistler.sfu.ca with SMTP (8.6.8/SFU-2.6H) id KAA20243 for (from vanepp); Thu, 28 Jul 1994 10:56:01 -0700 Received: by fraser.sfu.ca (920330.SGI/SFU-2.3C) id AA14439 for academic-firewalls@net.tamu.edu (from vanepp); Thu, 28 Jul 94 10:55:57 -0700 Message-Id: <9407281755.AA14439@fraser.sfu.ca> In-Reply-To: <199407281538.JAA00706@ncar.ucar.EDU> from "Greg Woods" at Jul 28, 94 09:38:22 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1745 Date: Thu, 28 Jul 1994 10:55:56 -0700 (PDT) Precedence: bulk From: Peter Van Epp Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Other Universities... > From: woods@ncar.UCAR.EDU (Greg Woods) ... > > > Also, how the user community accepts restrictions > > created by a firewall would be of interest. > > This is going to be a tough one. We just finished convincing management > that we need some kind of firewall. This was a much easier task now that > the machine on which our division director reads his mail was broken > into and was down for a day while the OS was re-installed :-) Nothing > like a little personal experience to convince someone. We are now considering > using packet filters to block almost all access into our network and make > all accesses go through a couple of application gateway machines and use > one-time passwords. I think for the interactive logins the user community > will eventually accept this, but they often send things in via automated > scripts that run in the middle of the night; they will be very upset at > having this capability taken away from them. Unfortunately I really do not > know any way we can protect ourselves against password sniffing without > one-time passwords. The most secure application gateway in the world > doesn't do any good if the bad guys can get hold of legitimate login > names and passwords. > > --Greg Greg: For the batch option one thing you might consider is installing kerberos and the Umich Kat server (covered in the last Usenix Security conference proceedings, I can dig up a reference if needed). This would require you to install servtabs for the remote sites (and require them to have a kerberos server up as well) but will address the batch issue and may be worth the hassle for that one application. Peter Van Epp / Operations and Technical Support Simon Fraser University, Burnaby, B.C. Canada -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 13:11:47 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id NAA15024 for academic-firewalls-j; Thu, 28 Jul 1994 13:11:26 -0500 Received: from whistler.sfu.ca (root@whistler.sfu.ca [142.58.103.1]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id NAA14985 for ; Thu, 28 Jul 1994 13:11:11 -0500 Received: from fraser.sfu.ca (vanepp@fraser.sfu.ca [128.189.32.21]) by whistler.sfu.ca with SMTP (8.6.8/SFU-2.6H) id LAA21617 for (from vanepp); Thu, 28 Jul 1994 11:11:04 -0700 Received: by fraser.sfu.ca (920330.SGI/SFU-2.3C) id AA16258 for academic-firewalls@net.tamu.edu (from vanepp); Thu, 28 Jul 94 11:11:00 -0700 Message-Id: <9407281811.AA16258@fraser.sfu.ca> In-Reply-To: <199407281538.JAA00706@ncar.ucar.EDU> from "Greg Woods" at Jul 28, 94 09:38:22 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1137 Date: Thu, 28 Jul 1994 11:10:59 -0700 (PDT) Precedence: bulk From: Peter Van Epp Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Other Universities... At present SFU does not have a firewall, and to some extent I am unsure that a firewall would be useful. All the security incidents that I am aware of have been from the inside (either directed at our machines or directed at other machines on the Internet from here), and a firewall that we could get approval for would not stop that. I have permission to install Drawbridge with no filtering enabled (I was at both the TAMU presentations at the Usenix Security conference 2 years ago), but have been overrun by a new problem: our regional net has upgraded to an ATM based WAN link among the Universities that provides peak Ethernet bandwidth between the sites (at the cost of a T1 line as long as the average traffic over a month is about T1). This of course provides an interesting new problem to firewalling: how do you implement a firewall without limiting the peak bandwidth. I suspect the answer is going to be a fast filtering router (or something like several Drawbridges connected in parallel in some interesting manner). Peter Van Epp / Operations and Technical Support Simon Fraser University, Burnaby, B.C. Canada -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 13:27:58 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id NAA15494 for academic-firewalls-j; Thu, 28 Jul 1994 13:27:27 -0500 Received: from posaune.tamu.edu (posaune [128.194.177.4]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id NAA15455 for ; Thu, 28 Jul 1994 13:27:09 -0500 Received: by posaune.tamu.edu (NX5.67d/NX3.0M) id AA01106; Thu, 28 Jul 94 13:23:50 -0500 Message-Id: <9407281823.AA01106@posaune.tamu.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) Date: Thu, 28 Jul 94 13:23:50 -0500 Precedence: bulk From: Dave Hess Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Other Universities... > At present SFU does not have a firewall, and to some extent I am unsure > that a firewall would be useful. All the security incidents that I am aware of > have been from the inside (either directed at our machines or directed at > other machines on the Internet from here), and a firewall that we could get > approval for would not stop that. I have permission to install Drawbridge with > no filtering enabled (I was at both the TAMU presentations at the Usenix > Security conference 2 years ago), but have been overrun by a new problem: > our regional net has upgraded to an ATM based WAN link among the Universities > that provides peak Ethernet bandwidth between the sites (at the cost of a T1 > line as long as the average traffic over a month is about T1). This of course > provides an interesting new problem to firewalling: how do you implement a > firewall without limiting the peak bandwidth. I suspect the answer is going to > be a fast filtering router (or something like several Drawbridges connected in > parallel in some interesting manner). Well, we ran into the same thing. We are about to upgrade our Internet connection from a T1 to a T3 (~45 Mb/s) and all of a sudden the 2Mb/s through our current Drawbridge machine is obviously not going to cut it. I'm working on a new version of Drawbridge that will use ODI drivers rather than directly accessing the hardware. It will also have frame support for Ethernet II or 802.2 SNAP. This will allow you to use just about any ethernet or FDDI cards you can find that have ODI drivers available for them. Token ring support is also possible and simple to do but won't be there initially. We don't have much of a need for it. Note that it will still be just a two port filtering bridge and both ports must be of the same media type. Dave - --- David K. Hess Network Analyst David-Hess@tamu.edu Computing and Information Services - Network Group (409) 845-0372 (work) Texas A&M University -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 13:50:29 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id NAA15812 for academic-firewalls-j; Thu, 28 Jul 1994 13:50:07 -0500 Received: from spsgate.sps.mot.com (spsgate.sps.mot.com [192.70.231.1]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id NAA15770 for ; Thu, 28 Jul 1994 13:49:48 -0500 Received: from mogate (mogate.sps.mot.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA18045; Thu, 28 Jul 94 11:49:45 MST Received: from motsps.sps.mot.com by mogate (4.1/SMI-4.1/Email-2.0) id AA09177; Thu, 28 Jul 94 11:49:42 MST Received: from mordor.sps.mot.com by motsps.sps.mot.com (4.1/SMI-4.1/Email-2.1) id AA04914; Thu, 28 Jul 94 11:49:39 MST Received: from strider.sps.mot.com by mordor.sps.mot.com (4.1/SMI-4.1) id AA02184; Thu, 28 Jul 94 13:49:32 CDT Message-Id: <9407281349.ZM8144@strider> X-Face: /o%}KXa4n{LbsPbf!#X?6]Pk,t476F$i!R+|8U}c,H$@Qv'=KZgN(xmNO{u/3IKVA[hL#sJp&WuQ(~{f';TGPtI}D[Df8D%IIddequND6@WsxPiV-/5M%W\TD,hK]%_^5\F>r3Ir2P\XjBEspCxlr IuYjp8\K7usv>MMXYE X-Mailer: Z-Mail (3.0.0 15dec93) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Date: Thu, 28 Jul 1994 13:49:31 -0500 Precedence: bulk From: "Brian Sinclair" Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: subscribe Please subscribe me - -- Regards, Brian Sinclair *:-) +================================================================+ | Final Manufacturing Group 6501 William Cannon Drive West | | Network & Systems Support Austin, Texas 78735 | | Section Manager Maildrop: OE-61 | | Motorola Oakhill Voice: (512) 891-3214 | | Fax: (512) 891-6157 | | | | Internal Addr: RXCH40@EMAIL or sinclair@strider | | Internet Addr: sinclair@strider.sps.mot.com | | Quickmail: RXCH41@EMAIL | +================================================================+ -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 15:09:59 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id PAA16794 for academic-firewalls-j; Thu, 28 Jul 1994 15:09:37 -0500 Received: from localhost (d1s8027@localhost) by net.tamu.edu (8.6.7/8.6.7) with SMTP id PAA16752 for ; Thu, 28 Jul 1994 15:09:20 -0500 In-reply-to: Your message of "Thu, 28 Jul 1994 08:51:10 PDT." <199407281551.IAA15301@Bump.Stanford.EDU> Message-ID: <16751.775426159@net.tamu.edu> Date: Thu, 28 Jul 1994 15:09:19 -0500 Precedence: bulk From: Douglas Lee Schales Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Texas A&M network security >Doug, I have some questions about your physical setup. I assume your >university network has one or more Internet connections connected to >some sort of hub with building subnets hanging off. Where does the >filter go in relationship to this setup? Outside a particular >protected building? Between the university and the Internet as a >whole? How many such filters do you have? How many hosts does a >typical filter protect? The (campus) network is presently a couple of FDDI rings with routers feeding ethernet segments into buildings. The packet filter sits between this network and the [Internet + TAMUS WAN]. The filter "shields" the x-thousand hosts on the campus network where x > 10. >experimented with alternatives. We are experimenting with >alternatives where firewalls are distributed according to >administrative boundaries within the university. This is inspired by >the way physical security is organized within universities. I think this is the way to go, but we would leave such decisions up to the departments. We currently have no internal packet filters, but with the installation of an Ethernet plant in 8 dorms this summer, that may change. >I also have some questions about your filtering policy. Do you allow >arbitrary packets out? UDP in? Protocols other than TCP or UDP? >What TCP services do you allow in and out? I assume that if you want >to protect students with + in hosts.equiv, you must filter out For the most part all TCP/UDP outbound traffic is allowed. System administrators often ask that traffic from a host/network be blocked, but we have no overall policy on that. For inbound, we allow most UDP, except for the really dangerous ones. On TCP by default, only SMTP is allowed for the most part. Other services must be requested. We can provide access lists on a per (inside) host basis. We have a strict policy that rlogin/rsh are not allowed for any host. Other network protocols (ICMP, IPX...) can't be filtered with our filter (at this time...). >incoming rlogin, rsh, rcp, telnet, etc. connections. Do graduate >students notice when they are unable to telnet to their workstations >from the other side of the firewall? Can they dial into their Yes... but since we've had the filter for 2 years, most of the faculty and students prepare ahead of time for some time of access, either by getting their machines cleared for telnet access, or by using an alternate machine. Dial-in access to workstations is not addressed. The environment here is very autonomous. The only involvement CIS has over most machines on campus is the network. The packet filter is currently the best way we install some policy controls on these machines. "You have to do xxxx before we'll allow yyyy..." What xxxx and yyyy are is the fun part... >workstations? How do you provide mail service while protecting their >workstations from sendmail bugs and incorrect configurations? When We don't... :(... the intrusion detection helps here... we've discussed setting up a mail gateway and forcing all inbound mail through there, but with the volume of mail received here, I'm not sure it would ever handle the load. Generally what we do is try to get the word out to people to upgrade their sendmail (it is the biggest problem, since it is allowed in to all the hosts), and for those that don't, when they get hit, they realize that they should have done it earlier and it gets done. >they telnet out, are external X clients able to connect to their >workstation's X server? Not without a request to have it opened to their machine. For PC's and Mac's with X servers, we don't consider this too much of a threat. UNIX is another situation though... >And finally, some questions on larger issues involved in setting up an >"academic firewall". Who are you trying to protect your machines >from? I see probably four levels here: curious students in other >departments, vandalous outsiders, outside research groups who want to >steal your ideas, and well-funded foreign intelligence agencies. How Our primary goal is to stop (err, slow down) intrusions from outside... >does your protection strategy differ for the administrative arm of >your organization (whose data is usually considered more sensitive >than that of the academic arm)? And, finally, to what degree do you >permit local administration of security systems? In otherwords, if a >certain group decided it was willing to trade off less security for >greater connectivity, would this be possible within your architecture? No. Not presently... and I'm not sure we would allow it. We usually have requests from remote sites to be brought inside, but we don't allow it. We will be revamping our external connections in the next few months, and with the new setup, we will offer filtering services to the remote sites. Doug. - -- Douglas Lee Schales Texas A&M University Doug.Schales@net.tamu.edu Computing & Information Services Networking Project -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 16:17:25 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id QAA17990 for academic-firewalls-j; Thu, 28 Jul 1994 16:16:53 -0500 Received: from NOC.cs.ruu.nl (edwin@degas.cs.ruu.nl [131.211.80.37]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id QAA17951 for ; Thu, 28 Jul 1994 16:16:37 -0500 Received: (from edwin@localhost) by NOC.cs.ruu.nl (8.6.8/8.6.6) id XAA12031 for academic-firewalls@net.tamu.edu; Thu, 28 Jul 1994 23:16:30 +0200 Message-Id: <199407282116.XAA12031@NOC.cs.ruu.nl> X-Organization: Department of Computer Science, Utrecht University, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. phone: +31-30-531805, telefax: +31-30-513791 X-400: G=Edwin;S=Kremer;OU=cs;O=ruu;PRMD=surf;ADMD=400net;C=nl X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3200 Date: Thu, 28 Jul 1994 23:16:29 +0200 (MDT) Precedence: bulk From: Edwin Kremer Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Other Universities... Douglas Lee Schales wrote: | We're curious about what other Universities are doing/considering in | regards to firewalling; items such as policies, procedures, activities, I can't speak for Utrecht University at large (uh well, I guess I could, but I'd prefer not to), but allow me to explain the situation at the Computer Science dept. The first step we took to protect our local networks, was to install some packet-filtering rules between our local networks and our connec- tion to the campus network to keep out some of the obvious nasty stuff. Access from the staff network to the Internet was not restricted by these rules; access from the Internet to our network (we have a lot of travelling staff who really need it) was limited to a few internal hosts that we watched more closely than all workstations scattered around. This setup evolved over the years (some in-house developed bastion host was operated for quite some time) and still does. After the last net-snooping incident, we moved on to a stronger means of authentica- tion: challenge/response one-time passwords. At the same time I started to compose and write down our local security policies. The first version of that document was given wider audience in a department's staff meeting and a few remarks were discussed. The next version will soon be officially approved by the department. We're still very liberate in what we allow our staff members to do on the Internet, but we try hard to educate them (actually, education was one of the main goals of our policy document). Without them knowing or noticing though, some programs are passed thru proxies on the firewall. Needless to say, not all staff members enjoy security measurements, but they are not unreasonable either. As long as we offer a well-documented, reliable Internet access service, they take a deep breath and do get used to those measurement quite easily. The student-networks are different matter: these are isolated from the staff networks and access to the Internet is fairly restricted (although this is not primarily for security reasons). About any security actions taken: At the university level, a Computer Emergency Response Team (CERT-UU) has been formed and officially installed by the university board. Apart from handling incidents, better security-awareness of the university community is one of the things the CERT-UU kernel-members try to achieve. I'm currently the chair of a university-wide forum of UNIX systems- and network administrators: we have our regular meetings every five or six weeks since october 1990, where we discuss UNIX system administration problems in general and security issues in particular. Well, that's about it for now. I must say that I find it very interesting to read what others have done or are planning to do. regards, --[ Edwin ]-- - -- Edwin H. Kremer, systems- and network manager. Dept. of Computer Science, Utrecht University, The Netherlands [WHOIS: ehk3] "Generally, he who occupies the field of battle first and awaits his enemy, is at ease." -- Sun Tzu -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 16:25:23 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id QAA18156 for academic-firewalls-j; Thu, 28 Jul 1994 16:24:59 -0500 Received: from ncar.UCAR.EDU (ncar.ucar.edu [192.52.106.6]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id QAA18117 for ; Thu, 28 Jul 1994 16:24:42 -0500 Message-Id: <199407282124.PAA27955@ncar.ucar.EDU> Received: by ncar.ucar.EDU (NCAR-local/ NCAR Central Post Office 03/11/93) id PAA27955; Thu, 28 Jul 1994 15:24:40 -0600 In-Reply-To: <9407281755.AA14439@fraser.sfu.ca>; from "Peter Van Epp" at Jul 28, 94 10:55 am X-Mailer: ELM [version 2.3 PL11] Date: Thu, 28 Jul 94 15:24:39 MDT Precedence: bulk From: woods@ncar.UCAR.EDU (Greg Woods) Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Other Universities... > require you to install servtabs for the remote sites (and require them to > have a kerberos server up as well) Since we've got "remote sites" literally all over the world, this is not a practical option for us. - --Greg -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 18:51:50 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id SAA19388 for academic-firewalls-j; Thu, 28 Jul 1994 18:51:34 -0500 Received: from POMONA.CLAREMONT.EDU (POMONA.CLAREMONT.EDU [134.173.4.160]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id SAA19350 for ; Thu, 28 Jul 1994 18:51:19 -0500 Received: from mickey.pomona.claremont.edu by POMONA.CLAREMONT.EDU (PMDF V4.3-8 #6077) id <01HF8WBRN1GG8WWFCB@POMONA.CLAREMONT.EDU>; Thu, 28 Jul 1994 16:51:07 -0700 (PDT) Received: from MICKEY/SpoolDir by mickey.pomona.claremont.edu (Mercury 1.12) ; Thu, 28 Jul 94 16:51:19 -0700 Received: from SpoolDir by MICKEY (Mercury 1.12); Thu, 28 Jul 94 16:51:08 -0700 Message-id: <178D853A08@mickey.pomona.claremont.edu> Organization: Pomona College X-Mailer: WinPMail v1.0 (R2) Content-transfer-encoding: 7BIT Priority: normal Date: Thu, 28 Jul 1994 16:51:03 -0700 Precedence: bulk From: sfrankel@POMONA.CLAREMONT.EDU Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Other Universities... I would very much appreciate a copy of your draft policy. Could you send it to me via this list, or some other way. Thank you. Steven Frankel Director of Information Technologies Pomona College Claremont, CA -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 19:34:39 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id TAA19923 for academic-firewalls-j; Thu, 28 Jul 1994 19:34:21 -0500 Received: from uvs1.orl.mmc.com (uvs1.orl.mmc.com [129.243.52.3]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id TAA19885 for ; Thu, 28 Jul 1994 19:33:58 -0500 Received: from TCCSLR.DECnet MAIL11D_V3 by uvs1.orl.mmc.com (5.57/Ultrix3.0-C) id AA11871; Thu, 28 Jul 94 20:26:46 -0400 Message-Id: <9407290026.AA11871@uvs1.orl.mmc.com> Date: Thu, 28 Jul 94 20:26:46 -0400 Precedence: bulk From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson, P.E. Information Security) Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Other Universities... Greg writes: >Unfortunately I really do not >know any way we can protect ourselves against password sniffing without >one-time passwords. The most secure application gateway in the world >doesn't do any good if the bad guys can get hold of legitimate login >names and passwords. The good news is that one-time-passwords are now relatively cheap. Where once the only solution was a $40-$60 token from Racal, Enigma, or SecurID now there are *software* based tokens available at a much lower per-user cost. After having been trying for years to gain OTP acceptance (current methods have had only one major change since Roman times - then they were changed daily) only to be shot down by bean-counters, now think there is a chance. Warmly, Padgett ps how do you subscribe to the commercial firewalls list ? -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 19:44:44 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id TAA20058 for academic-firewalls-j; Thu, 28 Jul 1994 19:44:23 -0500 Received: from hawksbill.sprintmrn.com (hawksbill.sprintmrn.com [199.11.1.3]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id TAA20020 for ; Thu, 28 Jul 1994 19:44:10 -0500 Received: by hawksbill.sprintmrn.com (5.65/1.34) id AA11434; Thu, 28 Jul 94 20:47:14 -0500 Message-Id: <9407290147.AA11434@hawksbill.sprintmrn.com> In-Reply-To: <9407290026.AA11871@uvs1.orl.mmc.com> from "A. Padgett Peterson, P.E. Information Security" at Jul 28, 94 08:26:46 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 502 Date: Thu, 28 Jul 1994 20:47:14 -0500 (EST) Precedence: bulk From: paul@hawksbill.sprintmrn.com (Paul Ferguson) Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Other Universities... > > ps how do you subscribe to the commercial firewalls list ? > Padgett, old buddy, send a subscribe message to: majordomo@greatcircle.com with a message body of: subscribe firewalls your@adddress.here.com _______________________________________________________________________________ Paul Ferguson US Sprint Managed Network Engineering tel: 703.904.2437 Herndon, Virginia USA internet: paul@hawk.sprintmrn.com -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 20:12:09 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id UAA20382 for academic-firewalls-j; Thu, 28 Jul 1994 20:11:47 -0500 Received: from bowen.cc.utas.edu.au (johnm@bowen.cc.utas.edu.au [131.217.10.6]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id UAA20344 for ; Thu, 28 Jul 1994 20:11:29 -0500 Received: (from johnm@localhost) by bowen.cc.utas.edu.au (8.6.8/8.6.6) id LAA01779; Fri, 29 Jul 1994 11:06:01 +1000 Sender: John Miezitis cc: academic-firewalls@net.tamu.edu In-Reply-To: <9407290026.AA11871@uvs1.orl.mmc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Date: Fri, 29 Jul 1994 11:05:41 +1000 (EST) Precedence: bulk From: John Miezitis Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Other Universities... On Thu, 28 Jul 1994 padgett@tccslr.dnet.mmc.com wrote: > Greg writes: > > ps how do you subscribe to the commercial firewalls list ? The following is the result of sending a help command to the listserver (Majordomo@GreatCircle.COM):- >>>> help This is Brent Chapman's "Majordomo" mailing list manager, Revision 1.46. It understands the following commands: subscribe [
] Subscribe yourself (or
if specified) to the named . unsubscribe [
] Unsubscribe yourself (or
if specified) from the named . which [
] Find out which lists you (or
if specified) are on. who Find out who is on the named . info Retrieve the general introductory information for the named . lists Show the lists served by this Majordomo server. help Retrieve this message. end Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of an email message to "Majordomo@GreatCircle.COM". Commands in the "Subject:" line NOT processed. If you have any questions or problems, please contact "Majordomo-Owner@GreatCircle.COM". >>>> >>>> -- END OF COMMANDS The list name is simply "firewalls". Hope this helps. Cheers. JohnM. John B Miezitis, University of Tasmania, Information Technology Services. Intl Ph: +61 02 207419, Email: John.Miezitis@its.utas.edu.au Belgium man Belgium!!! - Z. Beeblebrox _______________________________________________________________________________ -------- From academic-firewalls-owner@net.tamu.edu Thu Jul 28 21:14:55 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id TAA20154 for academic-firewalls-j; Thu, 28 Jul 1994 19:46:02 -0500 Received: from uvs1.orl.mmc.com (uvs1.orl.mmc.com [129.243.52.3]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id TAA20114 for ; Thu, 28 Jul 1994 19:45:39 -0500 Received: from TCCSLR.DECnet MAIL11D_V3 by uvs1.orl.mmc.com (5.57/Ultrix3.0-C) id AA11896; Thu, 28 Jul 94 20:36:58 -0400 Message-Id: <9407290036.AA11896@uvs1.orl.mmc.com> Date: Thu, 28 Jul 94 20:36:58 -0400 Precedence: bulk From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson, P.E. Information Security) Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Securing a supercomputer site >This is not possible with the schemes we are considering. We're talking about >the credit card sized devices that tell the user what the password is >for this particular login attempt. Possession of the device is required, >as is a PIN number, in order to be successfully authenticated. Now the device can be emulated in software - saw one at the CSI bash that just popped up a screen and the user entered a PIN - the actual challenge/ response pair was never displayed, all was automatic. The only drawback is that the clock in a PC is not stable enough for time-synchronous use though there is a way around this. >But that isn't going to be a general >solution for us, and it does bring up the more general issue of >how to pass traffic from one "secure" net to another across >an insecure connection between them. So consider this: the "tokenized" OTP is never transmitted. Instead it is used internally as a unique key for full session encryption and by the fact that you can communicate at all, you authenticate both ends. (Actually had this thought a couple of years ago but the technology just caught up recently.) Now the major problem would be a "man-in-the-middle" attack but there would a way around even this. Best part is that by using such encryption at a low level (2 or 3), all the user ever has to do is to enter his PIN, everything else is transparent. Warmly, Padgett -------- From academic-firewalls-owner@net.tamu.edu Fri Jul 29 10:54:52 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id KAA27982 for academic-firewalls-j; Fri, 29 Jul 1994 10:54:31 -0500 Received: from amdahl.com (amdahl.com [129.212.11.3]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id KAA27943 for ; Fri, 29 Jul 1994 10:54:16 -0500 Received: by amdahl.com (/\==/\ Smail #25.33) id ; Fri, 29 Jul 94 08:54 PDT Received: from idontcare.eng.amdahl.com by cliffy.eng.amdahl.com (4.1/SMI-4.1) id AA29269; Fri, 29 Jul 94 08:53:11 PDT Message-Id: <9407291553.AA29269@cliffy.eng.amdahl.com> Date: Fri, 29 Jul 94 08:53:11 PDT Precedence: bulk From: pjh70@eng.amdahl.com (Patrick J. Horgan ) Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Posting help for one person to a list When someone asks for help about something. And you have a reasonable expectation that most the people on the list already know about it... Perhaps it would be better to reply to them directly rather than to the list:) It'd keep the noise level down. I'd suspect that a lot of people on this list already know about, (and are on,) Brent's list. Happy thoughts, Patrick These opinions are mine, and not Amdahl's (except by coincidence;). ~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ / | | (\ \ | Patrick J. Horgan | Amdahl Corporation | \\ Have | | pjh70@eng.amdahl.com | 1250 East Arques Avenue | \\ _ Sword | | Phone : (408)992-2779 | P.O. Box 3470 M/S 201 | \\/ Will | | FAX : (408)773-0833 | Sunnyvale, CA 94088-3470 | _/\\ Travel | \ | | \) / ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~ . -------- From academic-firewalls-owner@net.tamu.edu Fri Jul 29 11:16:16 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id LAA28325 for academic-firewalls-j; Fri, 29 Jul 1994 11:15:52 -0500 Received: from rodin.os2lan.ny.cantor.com (rodin.cantor.com [198.80.21.2]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id LAA28286 for ; Fri, 29 Jul 1994 11:15:36 -0500 Received: by rodin.os2lan.ny.cantor.com (8.6.9) id MAA12987; Fri, 29 Jul 1994 12:14:50 -0400 Received: from unknown(148.106.20.145) by rodin via smap (V1.0mjr) id sma012985; Fri Jul 29 12:14:27 1994 Received: from cc:Mail by smtpgwy.cantor.com id AA775509421 Fri, 29 Jul 94 12:17:01 EST Encoding: 1434 Text Message-Id: <9406297755.AA775509421@smtpgwy.cantor.com> Date: Fri, 29 Jul 94 12:17:01 EST Precedence: bulk From: ashorsht@cantor.com Sender: academic-firewalls-owner@net.tamu.edu Errors-To: academic-firewalls-owner@net.tamu.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Posting help for one person to a list What excatly are you talking about? I am not sure which post you are referring to. ______________________________ Reply Separator _________________________________ Subject: Posting help for one person to a list Author: academic-firewalls@net.tamu.edu at Internet Date: 7/29/94 8:53 AM When someone asks for help about something. And you have a reasonable expectation that most the people on the list already know about it... Perhaps it would be better to reply to them directly rather than to the list:) It'd keep the noise level down. I'd suspect that a lot of people on this list already know about, (and are on,) Brent's list. Happy thoughts, Patrick These opinions are mine, and not Amdahl's (except by coincidence;). ~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ / | | (\ \ | Patrick J. Horgan | Amdahl Corporation | \\ Have | | pjh70@eng.amdahl.com | 1250 East Arques Avenue | \\ _ Sword | | Phone : (408)992-2779 | P.O. Box 3470 M/S 201 | \\/ Will | | FAX : (408)773-0833 | Sunnyvale, CA 94088-3470 | _/\\ Travel | \ | | \) / ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~ .