-------- From academic-firewalls-owner@net.tamu.edu Mon Oct 17 16:12:25 1994 In-reply-to: <199410140600.BAA23959@net.tamu.edu> from MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL23] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-length: 1327 Date: Tue, 18 Oct 1994 10:03:09 +1300 (NDT) From: rj.fulton@auckland.ac.nz Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Security Policies for Academic networks Greeting All, We are working towards establishing a security policy for the University's network. We have a screened subnet firewall setup but have been pushed into opening holes for some departments and have come to the conculsion that we need a comprehensive policy, supported by the University administration so we can evaluate such issues. I am interested in obtaining copies of what others have come up with in this area. Areas of concern include (in no particular order): 1/ Desktop single user system ( mainly virus) 2/ Multi-user system (mainly tcp and/or password based attacs) 3/ File servers (Both Novell and NFS) 4/ Router and other network infrstructure 6/ Otheers ???? I have found the Policy Archive on Purdue's Coast ftp archive but most of the documents there focus on 'acceptable use' policies. Thanks, Russell. +-------------------------------------------------------------------+ | Russell Fulton 'phone +64 9 373-7599 x 8955 | | Computer Centre fax +64 9 373-7425 | | University of Auckland email r.fulton@auckland.ac.nz | | Private Bag 92019 time gmt -12 (-13 oct - mar) | | Auckland, New Zealand. psi psi%5301970000073::r.fulton | +-------------------------------------------------------------------+ -------- From academic-firewalls-owner@net.tamu.edu Mon Oct 17 16:29:22 1994 Date: Mon, 17 Oct 94 16:23:42 CDT From: cprice@netserv.unmc.edu (Chad Price x7936) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Security Policies for Academic networks > We are working towards establishing a security policy for the > University's network. We have a screened subnet firewall setup but > have been pushed into opening holes for some departments and have > come to the conculsion that we need a comprehensive policy, supported > by the University administration so we can evaluate such issues. > > I am interested in obtaining copies of what others have come up with > in this area. > > Areas of concern include (in no particular order): > 1/ Desktop single user system ( mainly virus) > 2/ Multi-user system (mainly tcp and/or password based attacs) > 3/ File servers (Both Novell and NFS) > 4/ Router and other network infrstructure > 6/ Otheers ???? > > I have found the Policy Archive on Purdue's Coast ftp archive but > most of the documents there focus on 'acceptable use' policies. > > At the risk of sounding like a pedant, have you looked at RFC 1244?? Its a pretty extensive discussion of security issues and includes sample policies. Chad Price Univ NE Medical Center Omaha NE cprice@netserv.unmc.edu -------- From academic-firewalls-owner@net.tamu.edu Mon Oct 17 16:55:34 1994 X-Organization: Brigham & Womens Hospital, A Teaching Affiliate of Harvard Medical School In-Reply-To: ; from "rj.fulton@auckland.ac.nz" at Oct 18, 94 10:03 am X-PGP: 876BD629 Fingerprint: 70 93 32 D6 36 D4 04 10 40 EC AB 28 A4 1D 0F E2 Date: Mon, 17 Oct 94 17:49:56 EDT From: Adam Shostack Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Security Policies for Academic networks You wrote: | Greeting All, | We are working towards establishing a security policy for the | University's network. We have a screened subnet firewall setup but | have been pushed into opening holes for some departments and have | come to the conculsion that we need a comprehensive policy, supported | by the University administration so we can evaluate such issues. | | I am interested in obtaining copies of what others have come up with | in this area. | | Areas of concern include (in no particular order): | 1/ Desktop single user system ( mainly virus) | 2/ Multi-user system (mainly tcp and/or password based attacs) | 3/ File servers (Both Novell and NFS) | 4/ Router and other network infrstructure | 6/ Otheers ???? While you are doing a comprehensive review, don't assume that the same solution will cover all your departments. The undergraduate computer labs will probably be set up differently from the administrative computing networks. Do you want to seperate them with a firewall? Do students get accounts on departmental machines, or do you isolate the students to a network outside your firewall? You might want to give thought to how you will netowrk your dorms. You should probably say something about pirating software. I'd write up a policy statement for students, faculty & employees to sign, acknowledging that they have read & understood your acceptable use policies and agree to abide by them. Adam -------- From academic-firewalls-owner@net.tamu.edu Mon Oct 17 17:28:30 1994 In-Reply-To: <9410172103.AA02663@ccu1.auckland.ac.nz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 17 Oct 1994 16:19:33 -0600 (MDT) From: Dave Grisham Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Security Policies for Academic networks If it will help, I have a collection of various policies (Ethics, etc) at ftp.unm.edu Any policies that you may wish to view, may be found there. Submissions of policies for posting can be made to me: dave@unm.edu ftp.unm.edu Dave Grisham This site has a collection of ethics documents. Included are policies from many institutions. Look in the directory /ethics. Listserv@unmvm.unm.edu Dave Grisham This site has a collection of ethics documents. Included are policies from many institutions. Access is through normal listserv commands [get, help, etc] Look in the directory ETHICS. - -- grish Dave Grisham, Security Administrator Phone (505) 277-8032 FAX 277-8101 Computer & Information Resources & Technology Internet DAVE@unm.EDU Univ. of New Mexico Albuquerque, NM 87131 BITNET DAVE@UNMB.UNM.EDU On Tue, 18 Oct 1994 rj.fulton@auckland.ac.nz wrote: > Greeting All, > We are working towards establishing a security policy for the > University's network. We have a screened subnet firewall setup but > have been pushed into opening holes for some departments and have > come to the conculsion that we need a comprehensive policy, supported > by the University administration so we can evaluate such issues. > > I am interested in obtaining copies of what others have come up with > in this area. > > Areas of concern include (in no particular order): > 1/ Desktop single user system ( mainly virus) > 2/ Multi-user system (mainly tcp and/or password based attacs) > 3/ File servers (Both Novell and NFS) > 4/ Router and other network infrstructure > 6/ Otheers ???? > > I have found the Policy Archive on Purdue's Coast ftp archive but > most of the documents there focus on 'acceptable use' policies. > > Thanks, Russell. > +-------------------------------------------------------------------+ > | Russell Fulton 'phone +64 9 373-7599 x 8955 | > | Computer Centre fax +64 9 373-7425 | > | University of Auckland email r.fulton@auckland.ac.nz | > | Private Bag 92019 time gmt -12 (-13 oct - mar) | > | Auckland, New Zealand. psi psi%5301970000073::r.fulton | > +-------------------------------------------------------------------+ > > -------- From academic-firewalls-owner@net.tamu.edu Mon Oct 17 18:58:01 1994 In-Reply-To: <9410172103.AA02663@ccu1.auckland.ac.nz> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII content-length: 2237 Date: Mon, 17 Oct 1994 20:50:00 -0300 (ADT) From: Steve MacLeod Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Security Policies for Academic networks We have had discussions on how to properly secure our student environment, one suggestion has been to put a camera in each lab, for a few reasons ... 1) Try to prevent damage to equipment 2) Discourage theft 3) Make users accountable for their use of campus resources, sending fraud email, abusive messages and the like, they can't say "someone stole my password" when their smiling face is on tape . Has anyone else had any experience with cameras in the lab, is it too much "Big Brother"? Any other suggestions ? Thanks - -------------------------------------------------------------------- Steve MacLeod Microcomputer Specialist (902)539-5300x625 Computer Centre University College of Cape Breton Sydney, N.S. Fax (902)562-0119 Canada B1P 5S2 On Tue, 18 Oct 1994 rj.fulton@auckland.ac.nz wrote: > Greeting All, > We are working towards establishing a security policy for the > University's network. We have a screened subnet firewall setup but > have been pushed into opening holes for some departments and have > come to the conculsion that we need a comprehensive policy, supported > by the University administration so we can evaluate such issues. > > I am interested in obtaining copies of what others have come up with > in this area. > > Areas of concern include (in no particular order): > 1/ Desktop single user system ( mainly virus) > 2/ Multi-user system (mainly tcp and/or password based attacs) > 3/ File servers (Both Novell and NFS) > 4/ Router and other network infrstructure > 6/ Otheers ???? > > I have found the Policy Archive on Purdue's Coast ftp archive but > most of the documents there focus on 'acceptable use' policies. > > Thanks, Russell. > +-------------------------------------------------------------------+ > | Russell Fulton 'phone +64 9 373-7599 x 8955 | > | Computer Centre fax +64 9 373-7425 | > | University of Auckland email r.fulton@auckland.ac.nz | > | Private Bag 92019 time gmt -12 (-13 oct - mar) | > | Auckland, New Zealand. psi psi%5301970000073::r.fulton | > +-------------------------------------------------------------------+ > > -------- From academic-firewalls-owner@net.tamu.edu Mon Oct 17 19:24:00 1994 In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 18 Oct 1994 10:13:32 +1000 (EST) From: Brian Meilak Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Security Policies for Academic networks On Mon, 17 Oct 1994, Steve MacLeod wrote: > > We have had discussions on how to properly secure our student > environment, one suggestion has been to put a camera in each lab, for a > few reasons ... > > 1) Try to prevent damage to equipment > 2) Discourage theft > 3) Make users accountable for their use of campus resources, sending > fraud email, abusive messages and the like, they can't say "someone > stole my password" when their smiling face is on tape . > Our lab administrator put cameras in all our labs. So far things are working ok. The cameras are the motion detection type. Everything goes to tape. Answering the points above: 1) damage to our lab equipment has dropped. 2) occurances of theft have dropped. 3) We have been able to identify students at machines who have been up to no good. You'll be suprised at what the camera's pick up!. Our students thought turning the lights out at night would hide what they were doing. And you'll find out who's visiting the labs at strange hours. > Has anyone else had any experience with cameras in the lab, is it too > much "Big Brother"? We have notices up everywhere saying that we have cameras in use. It is worth the $$$ as your costs due to theft and damage can cost you the same. bye! - ---- Brian Meilak E-Mail: B.Meilak@fit.qut.edu.au Senior Systems Programmer WEB : http://www.fit.qut.edu.au/~brian Faculty of Information Technology _--_|\ Queensland University of Technology / QUT Box 2434, Brisbane 4001, AUSTRALIA \_.--._/ Room ITE616 Phone: +61 7 864-2757 Fax: 864-1959 v -------- From academic-firewalls-owner@net.tamu.edu Mon Oct 17 19:43:36 1994 In-Reply-To: from "Steve MacLeod" at Oct 17, 94 08:50:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 574 Date: Mon, 17 Oct 1994 19:36:28 -0500 (CDT) From: Mike Moseler Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Security Policies for Academic networks > We have had discussions on how to properly secure our student > environment, one suggestion has been to put a camera in each lab, for a > few reasons ... [portion deleted] > 3) Make users accountable for their use of campus resources, sending > fraud email, abusive messages and the like, they can't say "someone > stole my password" when their smiling face is on tape . This won't stop people from doing it in their dorm room if you have modem dialin lines. - --- Mike Moseler mike@infocore.com Infocore Systems http://www.inlink.com -------- From academic-firewalls-owner@net.tamu.edu Mon Oct 17 20:55:42 1994 In-Reply-To: <199410180036.TAA17057@zen.infocore.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII content-length: 1111 Date: Mon, 17 Oct 1994 22:47:44 -0300 (ADT) From: Steve MacLeod Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Security Policies for Academic networks On Mon, 17 Oct 1994, Mike Moseler wrote: > > We have had discussions on how to properly secure our student > > environment, one suggestion has been to put a camera in each lab, for a > > few reasons ... > > [portion deleted] > > > 3) Make users accountable for their use of campus resources, sending > > fraud email, abusive messages and the like, they can't say "someone > > stole my password" when their smiling face is on tape . > > This won't stop people from doing it in their dorm room if you have > modem dialin lines. > > --- > Mike Moseler mike@infocore.com > Infocore Systems http://www.inlink.com > That's true, I am putting wrappers on what machines I can, definitely the SUN Solaris 2.3 host and as for the Novell file servers running Mercury, I am hoping to turn on whatever logging it supports, might even have to look at Charon again (boo hiss!). If we can get some kind of a handle as to either the machine involved, or in the case of the lab/novell workstations, who was accessing the machine and when, we hope to discourage / repremand abusers. -------- From academic-firewalls-owner@net.tamu.edu Mon Oct 17 20:57:19 1994 In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 18 Oct 1994 11:56:12 +1000 (EST) From: Paul Pyyvaara Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Security Policies for Academic networks On Mon, 17 Oct 1994, Steve MacLeod wrote: > Has anyone else had any experience with cameras in the lab, is it too > much "Big Brother"? We had cameras installed into our general access lab which include a time stamp on recordings which are stored for one month. Since then we have had very few incidents of theft - we have even had a student suspended and fined for sending fraud e-mail - he was identified off one of our tapes. Paul. _____ /\____\ /\ Paul Pyyvaara - paulp@Bond.edu.au / / ___ \_____ _____ _____/ /\ http://Bond.edu.au/People/paulp.html / / /_\/ /\____\ /\____\ /\____\/ / / / ___ ; from "Brian Meilak" at Oct 18, 94 10:13 am X-PGP: 876BD629 Fingerprint: 70 93 32 D6 36 D4 04 10 40 EC AB 28 A4 1D 0F E2 Date: Tue, 18 Oct 94 1:04:38 EDT From: Adam Shostack Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Security Policies for Academic networks | > We have had discussions on how to properly secure our student | > environment, one suggestion has been to put a camera in each lab, for a | > few reasons ... | > | > 1) Try to prevent damage to equipment | > 2) Discourage theft | > 3) Make users accountable for their use of campus resources, sending | > fraud email, abusive messages and the like, they can't say "someone | > stole my password" when their smiling face is on tape . | We have notices up everywhere saying that we have cameras in use. | It is worth the $$$ as your costs due to theft and damage can cost | you the same. I would guess that fake cameras would give you 1 & 2 pretty well. Its also a lot cheaper than real cameras, a month worth of video tape, etc. Not to mention much less Big Brotherish. Adam -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 04:09:56 1994 Date: Tue, 18 Oct 94 10:02:39 BST From: Dave Mitchell Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: secure X? My dept has recently connected to the Internet. Currently I'm filtering out port 6000 on the link between the dept and the rest of the campus, but (not unreasonably), my users would like to run X apps on some of the central campus "hot boxes", displaying on X servers within the dept. Anyone know of safe(ish) ways of doing this? The X servers are a mixed bunch of Suns, PCs, dedicated X terminals etc, so providing a modified server is probably out of the question. One thought that did occur to me was to use a utility similar to xscope. This would set itself up as client to the X server listening on port 6000, and then itself start listening for connections on port 6001. Each time it receives a connection, it pops up a dialogue box saying "connection from x.y.z: ok to proceed?". If the user affirms, then the program just sits there copying data back and forth between the app and the server. I could then turn off filtering to port 6001, and tell users that if they want to run a remote app, start up this xscope-thingy on a departmental machine, then on the remote host set DISPLAY to xxx.dcs.shef.ac.uk:1 Before I rush off and start coding, does anyone know of an existing program that does such a thing - or have a better solution? Thanks, Dave. * David Mitchell, Systems Administrator, email: D.Mitchell@dcs.shef.ac.uk * Dept. Computer Science, Sheffield Uni. phone: +44 114-282-5573 * 211 Portobello St, Sheffield S1 4DP, UK. fax: +44 114-278-0972 * * Standards (n). Battle insignia or tribal totems -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 08:53:44 1994 Date: Tue, 18 Oct 94 09:41:38 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson, P.E. Information Security) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Identification >If we can get some kind of a handle as >to either the machine involved, or in the case of the lab/novell >workstations, who was accessing the machine and when, we hope to >discourage / repremand abusers. With Novell you can get both - the little used "node id" is actually the six byte unique ID of the NIC board in a PC or MAC. When we moved to our new facility as part of the punch-down process all NIC ids were recorded and are verified on each login. A number of months ago, we had an incident when something was repeatedly banging on the supervisor account on a server across town. The log enabled us to pinpoint the machine causing the problem and someone from security was at the machine within five minutes. Word got around 8*). Warmly, Padgett -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 10:47:19 1994 X-Organization: Brigham & Womens Hospital, A Teaching Affiliate of Harvard Medical School In-Reply-To: <9410180902.AA27259@dcs.shef.ac.uk>; from "Dave Mitchell" at Oct 18, 94 10:02 am X-PGP: 876BD629 Fingerprint: 70 93 32 D6 36 D4 04 10 40 EC AB 28 A4 1D 0F E2 Date: Tue, 18 Oct 94 11:41:00 EDT From: Adam Shostack Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? You wrote: | Before I rush off and start coding, does anyone know of an existing | program that does such a thing - or have a better solution? The latest firewalls toolkit does this. ftp.tis.com Adam -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 11:24:52 1994 In-Reply-To: <9410180902.AA27259@dcs.shef.ac.uk> from "Dave Mitchell" at Oct 18, 94 10:02:39 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 253 Date: Tue, 18 Oct 1994 09:19:10 -0700 (PDT) From: broadley@turing.ucdavis.edu (Bill Broadley) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? Whats wrong with the current .Xauthority? Noone can connect to your screen that doesn't have a password/key. - -- Bill Broadley Broadley@math.ucdavis.edu UCD Math Sys-Admin Linux is great. http://ucdmath.ucdavis.edu/~broadley PGP-ok -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 11:59:57 1994 Date: Tue, 18 Oct 94 17:53:45 BST From: Dave Mitchell Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? >Whats wrong with the current .Xauthority? Noone can connect to your >screen that doesn't have a password/key. the problem is that users will be wanting to run Xapps from machines in a different adminitrative domain, ie no common home directory. Thus, they must use the fiddly "xauth merge" stuff. Most of them will instead immedately do an "xhosts +" Unless I remove all copies of xhost from my system, and ban people from either copying a binary from elsewhere, or rebuilding it from the X11 src, this will always be the way. I dont want to enable port 6000 unless I am convinced that all X servers in the dept recognise MIT-MAGIC-COOKIE-1, and that no user will ever use "xhosts +". I think this is unlikely. Dave. * David Mitchell, Systems Administrator, email: D.Mitchell@dcs.shef.ac.uk * Dept. Computer Science, Sheffield Uni. phone: +44 114-282-5573 * 211 Portobello St, Sheffield S1 4DP, UK. fax: +44 114-278-0972 * * Standards (n). Battle insignia or tribal totems -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 12:37:15 1994 In-Reply-To: Your message of "Tue, 18 Oct 1994 17:53:45 -0000." Date: Tue, 18 Oct 1994 13:31:31 -0400 From: Bill Bogstad Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? >From: Dave Mitchell >To: academic-firewalls@net.tamu.edu >Subject: Re: secure X? > >>Whats wrong with the current .Xauthority? Noone can connect to your >>screen that doesn't have a password/key. > >the problem is that users will be wanting to run Xapps from machines >in a different adminitrative domain, ie no common home directory. Thus, >they must use the fiddly "xauth merge" stuff. Most of them will instead >immedately do an "xhosts +" > >Unless I remove all copies of xhost from my system, and ban people from >either copying a binary from elsewhere, or rebuilding it from the X11 >src, this will always be the way. Well, if you have source to your X server software it might be possible to modify all of your servers to not allow host based authentication/authorization. Building ones own X server tends to be more difficult then random X clients. Of course, this means more work for you as well... Bill Bogstad bogstad@cs.jhu.edu Computer Systems Manager JHU CS Department -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 12:55:13 1994 In-Reply-To: <199410181731.MAA00426@net.tamu.edu>; from "Bill Bogstad" at Oct 18, 94 1:31 pm X-Mailer: ELM [version 2.3 PL11] Date: Tue, 18 Oct 94 11:49:35 MDT From: woods@ncar.UCAR.EDU (Greg Woods) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? > Well, if you have source to your X server software it might be > possible to modify all of your servers to not allow host based > authentication/authorization. And again, unless you don't allow the users access to the compiler and also prevent them from bringing in any binaries from outside, you can't prevent them from using their own X server to get around these restrictions. - --Greg -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 13:04:29 1994 Date: Tue, 18 Oct 1994 18:58:36 +0100 From: Werner Fink Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? Ok, let's take a short script: #!/bin/sh title="-T " iconName="-n " if [ -z "${DISPLAY}" ]; then echo "No DISPLAY variable" 2>1& exit 2 fi if [ "`echo $DISPLAY | grep '^:'`" = "$DISPLAY" ]; then disp="$HOSTNAME:0" list="$HOSTNAME:0 $DISPLAY" else disp="$DISPLAY" list="$disp" fi if [ "$1" = "all" ]; then rechner="host1 host2 host3" ico="-ls -iconic" else rechner="$*" ico="-ls" fi for host in $rechner; do xauth extract - $list | \ rsh $host \ "xauth merge - ; \ setenv TERM xterm; \ setenv DISPLAY $disp; \ exec xterm ${ico} ${title}$host ${iconName}$host \ & /dev/null" & done exit 0 - --------------- Replace xterm and the options by your choice. Note that rsh should work without password within your LAN. Werner -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 13:08:05 1994 Date: Tue, 18 Oct 94 19:01:51 BST From: Dave Mitchell Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? > Well, if you have source to your X server software it might be >possible to modify all of your servers to not allow host based >authentication/authorization. Building ones own X server tends to be more >difficult then random X clients. Of course, this means more work for you as >well... modifying servers isnt an option - for example, we use commercial windoze-based X servers for our PCs. -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 13:22:44 1994 Date: Tue, 18 Oct 1994 14:15:03 -0400 From: Steve Kotsopoulos Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? Dave Mitchell wrote: > >Whats wrong with the current .Xauthority? Noone can connect to your > >screen that doesn't have a password/key. > > the problem is that users will be wanting to run Xapps from machines > in a different adminitrative domain, ie no common home directory. Thus, > they must use the fiddly "xauth merge" stuff. Most of them will instead > immedately do an "xhosts +" You can take the 'fillding' out of using xauth by wrapping it in an easy-to-use script. I've done that here, so that people will be less likely to resort to using xhost. Here's the script, called addauth: #! /bin/sh # # addauth - by Steve Kotsopoulos # # Usage: addauth [ host | user@host ] # portability warning: not all systems support "rsh user@host" # case $# in 0) echo 'usage: addauth [ host | user@host ]'; exit ;; *) xauth extract - $DISPLAY | rsh $1 xauth merge - ;; esac -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 13:42:53 1994 In-Reply-To: <199410181749.LAA02832@ncar.ucar.EDU> from "Greg Woods" at Oct 18, 94 11:49:35 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 670 Date: Tue, 18 Oct 1994 11:37:10 -0700 (PDT) From: broadley@turing.ucdavis.edu (Bill Broadley) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? > > > Well, if you have source to your X server software it might be > > possible to modify all of your servers to not allow host based > > authentication/authorization. > > And again, unless you don't allow the users access to the compiler and > also prevent them from bringing in any binaries from outside, you can't > prevent them from using their own X server to get around these restrictions. > > --Greg > You need root to run a xserver usually. Ya can't write direct to the frame buffer without root in most cases. - -- Bill Broadley Broadley@math.ucdavis.edu UCD Math Sys-Admin Linux is great. http://ucdmath.ucdavis.edu/~broadley PGP-ok -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 14:04:45 1994 Date: Tue, 18 Oct 94 19:58:33 BST From: Dave Mitchell Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? >The latest firewalls toolkit does this. ftp.tis.com I've had a quick look at fwtk-v1.2.tar.Z, but I cant see anyhting which obviously does what I want. Is there any particular utility I should be looking at? Dave. -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 14:14:07 1994 In-reply-to: Bill Broadley's message of Tue, 18 Oct 1994 11:37:10 -0700 (PDT) <9410181837.AA21181@turing.ucdavis.edu> Date: Tue, 18 Oct 1994 12:07:57 -0700 From: Kenneth Duda Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: secure X? > > > Well, if you have source to your X server software it might be > > possible to modify all of your servers to not allow host based > > authentication/authorization. > > And again, unless you don't allow the users access to the compiler and > also prevent them from bringing in any binaries from outside, you can't > prevent them from using their own X server to get around these restrictions. > > --Greg > Another point here is that if your users are suicidal there's not much you can do. I buy your argument that you need to make circumventing your protections harder than "xhost +". However, if one has to build their own X server to open themselves up to attack, I would think you could accept this risk. Do you feel you need to feel responsible for the security of a user who does things like building his own X server? How about a user who likes to run a process that binds to a random TCP port, and executes anything sent to that port as a shell command? 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 Tue Oct 18 15:22:18 1994 In-reply-to: <199410180600.BAA19360@net.tamu.edu> from MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL23] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-length: 1589 Date: Wed, 19 Oct 1994 09:16:14 +1300 (NDT) From: rj.fulton@auckland.ac.nz Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Cameras in Labs > > We have had discussions on how to properly secure our student > environment, one suggestion has been to put a camera in each lab, for a > few reasons ... > > 1) Try to prevent damage to equipment > 2) Discourage theft > 3) Make users accountable for their use of campus resources, sending > fraud email, abusive messages and the like, they can't say "someone > stole my password" when their smiling face is on tape . > > Has anyone else had any experience with cameras in the lab, is it too > much "Big Brother"? > We have had cameras in the public terminal area of the Computer Centre for several years ( > 5 ). The room is open long hours (now 24 during the week) and we have not lost any equipment or had problems with vandalism since we installed the cameras. The monitors are up in the operations area. During the same period we have had problems in other areas of the campus where there were no cameras installed. Now that the time lasped recorders are affordable we may well install more cameras particularly if we start opening labs without supervision... Russell. +-------------------------------------------------------------------+ | Russell Fulton 'phone +64 9 373-7599 x 8955 | | Computer Centre fax +64 9 373-7425 | | University of Auckland email r.fulton@auckland.ac.nz | | Private Bag 92019 time gmt -12 (-13 oct - mar) | | Auckland, New Zealand. psi psi%5301970000073::r.fulton | +-------------------------------------------------------------------+ -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 16:36:26 1994 X-Sender: ianh@monster.resmel.bhp.com.au Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Oct 1994 07:30:38 +1000 From: ianh@resmel.bhp.com.au (Ian Hoyle) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? >>The latest firewalls toolkit does this. ftp.tis.com > >I've had a quick look at fwtk-v1.2.tar.Z, but I cant see anyhting which >obviously does what I want. Is there any particular utility I should be >looking at? Have a look in the patches directory for the latest alpha release. There is an X proxy x-gw buried in there, ian - --- : Ian Hoyle, Senior Research Scientist /\/\ : BHP Research / / /\ : 245 Wellington Rd, Mulgrave, 3170, AUSTRALIA / / / \ : Phone +61-3-560-7066 / / / /\ \ : E-mail ianh@resmel.bhp.com.au \ \/ / / / : \ / / / : "Happy, happy, joy, joy ......" \/\/\/ : -- Ren & Stimpy ;) -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 16:46:25 1994 In-Reply-To: <9410181858.AA15220@dcs.shef.ac.uk>; from "Dave Mitchell" at Oct 18, 94 7:58 pm X-Mailer: ELM [version 2.3 PL11] Date: Tue, 18 Oct 94 15:40:44 MDT From: woods@ncar.UCAR.EDU (Greg Woods) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? > I've had a quick look at fwtk-v1.2.tar.Z, but I cant see anyhting which > obviously does what I want. Is there any particular utility I should be > looking at? Check out the Xforward package at crl.dec.com:pub/DEC/xforward.tar.Z I wrote a proxy server that accepts a telnet connection, authenticates through the TIS FWTK authentication server, and invokes xforward. However, I'm sure I've heard the TIS people say that an X windows proxy server will soon be included in the TIS FWTK, if it isn't already. - --Greg -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 17:11:59 1994 In-Reply-To: <199410181907.MAA28249@Bump.Stanford.EDU>; from "Kenneth Duda" at Oct 18, 94 12:07 pm X-Mailer: ELM [version 2.3 PL11] Date: Tue, 18 Oct 94 16:06:21 MDT From: woods@ncar.UCAR.EDU (Greg Woods) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? > However, if one has to build > their own X server to open themselves up to attack, I would think you > could accept this risk. I think that depends on what you are trying to protect and how sophisticated your users are. I don't think you can make that a blanket statement for everybody here. >Do you feel you need to feel responsible for > the security of a user who does things like building his own X server? Yes, I do, if a hacker can use this X server to get on to that users system and attack some of the systems I want to protect from there. The only other alternative is to also protect the secure systems from the user's workstations and that's the kind of user pain I'm trying to avoid. I'm willing to trust our own users to some extent, but I'm not willing to trust everybody on the Internet. That is to say, I'm willing to trust our own users not to deliberately damage our systems, but I don't want to trust them with enforcing our security policy. Users will tend to do things that make it more convenient for them to do their work (e.g. xhosts +) that can compromise our security, without realizing that they are doing so, even if they would not deliberately cause damage. I have to make sure that nothing one of our users does can compromise our security and work under the constraint that I have no control over, and in some cases not even any access to, our individual users' machines. This means that if I want to allow a user with a workstation free access to log in on the CRAY, then just protecting the CRAY from the Internet is not sufficient, I must also either protect the user's workstation from the Internet or the CRAY from the user's workstation, and I don't want to have to do the latter. That means I have to make sure that even if the user types "xhost +" or installs their own X server, it doesn't compromise our security. The only way I know to do that is not to allow free access from the Internet to the X servers on users' workstations. But the users do occasionally have a legitimate need to run an X application on a remote machine with the display on their workstation, and that leads naturally to a need for a proxy server for X that can allow such connections to be established, but only if they are authenticated by one of our users first. This seems to be a reasonable compromise between security and letting the users get their work done (at least, in our environment it seems reasonable). > How about a user who likes to run a process that binds to a random TCP > port, and executes anything sent to that port as a shell command? I think I do need to make sure that Joe Random Hacker on the Internet cannot access this port, yes. - --Greg -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 18:40:07 1994 In-reply-to: from "Chad Price x7936" at Oct 17, 94 04:23:42 pm MIME-version: 1.0 X-Mailer: ELM [version 2.4 PL23] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Content-length: 793 Date: Wed, 19 Oct 1994 12:33:31 +1300 (NDT) From: rj.fulton@auckland.ac.nz Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Security Policies for Academic networks Greetign Chad, Thanks for the pointer... > > > We are working towards establishing a security policy for the > > University's network. We have a screened subnet firewall setup but > > have been pushed into opening holes for some departments and have > > come to the conculsion that we need a comprehensive policy, supported > > by the University administration so we can evaluate such issues. > > At the risk of sounding like a pedant, have you looked at RFC 1244?? Its a > pretty extensive discussion of security issues and includes sample policies. It never hurts to point out the obvious, many of us (myself included) can't see what is right under our noses. As it happens I had found references to the RFC while poking around the COAST archive and have a copy now. Cheers, Russell. -------- From academic-firewalls-owner@net.tamu.edu Tue Oct 18 22:21:09 1994 Date: Tue, 18 Oct 1994 23:15:27 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Cameras in Labs Has anyone ever stolen the cameras? _ _ __ _ __ (/_ / (/ \/ \ _ __ __ ____ _ __ (/ _ __ _) / / . / )_(_)_/ (_/ (_(_) (_(_( /___(_)_/ )_(_) ( ( ( _) H. Morrow Long, Mgr of Dev., Yale Univ., Comp Sci Dept, 011 AKW, New Haven, CT 06520-8285, VOICE: (203)-432-{1248,1254} FAX: (203)-432-0593 INET: Long-Morrow@CS.Yale.EDU UUCP: yale!Long-Morrow BITNET: Long-Morrow@YaleCS WWW: http://www.cs.yale.edu/HTML/YALE/CS/HyPlans/long-morrow.html -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 02:10:58 1994 Date: Wed, 19 Oct 1994 00:05:52 -0700 From: Brent Chapman Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Cameras in Labs long-morrow@CS.YALE.EDU (H Morrow Long) writes: # Has anyone ever stolen the cameras? No, but see the appended message for Berkeley's take on the problem... :-) - -Brent - -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From: CLIFF@CMSA.BERKELEY.EDU (Cliff Frost {510} 642-5360) Path: agate!agateway!CMSA.BERKELEY.EDU!CLIFF Newsgroups: ucb.net.announce Subject: Networking with the Angels Date: 11 Aug 94 23:18:00 GMT Hi, Another story for your Only In Berkeley files: Yesterday morning one of the campus network links was vandalized by a person or persons unknown. Followers of these news items know that we have connected the networks at several off-campus sites with ethernet running through the air over Infrared laser beams. These connections have been very stable, but yesterday one of them ceased to funtion at 5:34am after someone climbed onto the roof of a building, cut both the laser's power cable and network connection, and spray-painted the lens with blue paint. The vandal(s) left a scrawled note, which read: Don't try to fix or replace this camera or you will be prosecuted for invasion of privacy. Don't with the Hell's Angels. If you fix and replace this camera you will be prostituted and prosecuted. Really. The units do look sort of/kinda like they might be cameras, but they aren't pointed at any private dwellings. We had the link back up in a couple of hours, and left a note explaining that it isn't a camera and we really aren't interested in spying on anyone. Really. Cliff Frost Network Services ps The police were called and are taking this seriously. pps The occupants of the building have placed a substantial barrier over the only external access to the roof of their building. -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 09:25:38 1994 Posted-Date: Wed, 19 Oct 1994 10:19:29 -0400 Date: Wed, 19 Oct 1994 10:19:29 -0400 From: millar@pobox.upenn.edu (Dave Millar) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Secure Lab Access (Was Re: Cameras in Labs) The problem: Unauthenticated access from backbone-connected PCs and Macs running IP clients (telnet, ftp, gopher, mosaic, etc.) with no logging. The solutions I've seen: - -Firewall off the network and restrict access to within your own domain (not too desirable since it completely denies Internet access from the labs, and you allows anonymous attacks from labs against your local hosts). - -Some kind of card reader on each Mac/PC (expensive to acquire and administer, and probably easy to bypass by breaking desktop security and installing your own tcp/ip stack). - -Authentication for other services (such as printing) is used to authenticate outbound internet connections from the lab. Not too familiar with this. Is the authentication a desktop-based application? Even if it isn't, what stops someone from installing their own tcp/ip stack on the desktop and making unauthenticated connections? - -Cameras (already discussed) - -Some kind of gateway between the lab and the backbone, which would require authentication before going any further and would maintain logs of all connections. This seems like the most promising alternative, though there may be some concerns about throughput. Has anybody seen/done anything like this? Firewalls seem to be based on restricting access to/from by protocol(port)/address. Is there some way to configure a gateway(firewall?) to require account/password authentication, and then pass through any and all protocols, while logging all connections by account? Anybody got any specifics? Any other possible solutions? Dave _________________________________________________ Dave Millar University Information Security Officer 3401 Walnut St., Suite 335B Philadelphia, PA 19104-6228 University of Pennsylvania For security matters: security@isc.upenn.edu (read by Data Admin. staff) Other matters: millar@pobox.upenn.edu voice: (215) 898-2172 fax: (215) 898-1729 For PGP 2.6 Public key: http://www.upenn.edu/security-privacy/ PGP Fingerprint: 28 FB 09 DC C7 96 C2 53 1A B8 BE 3B 73 32 46 4C -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 09:33:44 1994 Posted-Date: Wed, 19 Oct 1994 10:27:33 -0400 Date: Wed, 19 Oct 1994 10:27:33 -0400 From: millar@pobox.upenn.edu (Dave Millar) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Secure Lab Access (Was Re: Cameras in Labs) >The problem: Unauthenticated access from backbone-connected PCs and Macs >running IP clients >(telnet, ftp, gopher, mosaic, etc.) with no logging. Before somebody suggests Kerberos: 1. These are all diskful desktops. What's to stop lab users from installing their own protocol stack and ip clients and bypassing? 2. Probably 99.9% of the servers labs users want to get to are not kerberized. 3. Kerberizing Mac and PC IP clients is probably out of the question. Too my knowledge, there aren't too may out there off the shelf. Dave _________________________________________________ Dave Millar University Information Security Officer 3401 Walnut St., Suite 335B Philadelphia, PA 19104-6228 University of Pennsylvania For security matters: security@isc.upenn.edu (read by Data Admin. staff) Other matters: millar@pobox.upenn.edu voice: (215) 898-2172 fax: (215) 898-1729 For PGP 2.6 Public key: http://www.upenn.edu/security-privacy/ PGP Fingerprint: 28 FB 09 DC C7 96 C2 53 1A B8 BE 3B 73 32 46 4C -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 10:17:43 1994 Date: Wed, 19 Oct 94 10:11:59 -0500 From: Dave Hess Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Secure Lab Access (Was Re: Cameras in Labs) > -Some kind of gateway between the lab and the backbone, which would require > authentication before going any further and would maintain logs of all > connections. This seems like the most promising alternative, though there > may be some concerns about throughput. Has anybody seen/done anything > like this? Firewalls seem to be based on restricting access to/from by > protocol(port)/address. Is there some way to configure a > gateway(firewall?) to require account/password authentication, and then > pass through any and all protocols, while logging all connections by > account? Anybody got any specifics? The ISI "Tunnel" works along these principals. Don't know if it is freely available or not. Annette DeSchon is one of the authors on the 1993 paper I have about it. 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 Oct 19 10:55:54 1994 In-reply-to: Greg Woods's message of Tue, 18 Oct 94 16:06:21 MDT <199410182206.QAA22287@ncar.ucar.EDU> Date: Wed, 19 Oct 1994 08:49:42 -0700 From: Kenneth Duda Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: secure X? >> > However, if one has to build >> > their own X server to open themselves up to attack, I would think you >> > could accept this risk. >> >> I think that depends on what you are trying to protect and how sophisticated >> your users are. I don't think you can make that a blanket statement >> for everybody here. Of course, your statement is true. When I said "I would think _you_ could accept this risk," I meant "I think Greg Woods could accept this risk," not "every system administrator could accept this risk." Thus, I was specifically making assumptions about your security needs based on being an academic institution (as opposed to a financial institution using your net to move millions of dollars around). You disagree with my assumption, i.e., you have decided that students need more protection than I thought. You [Greg Woods] say you have the following objective, which I will call "Woods' Goal": >> I have to make sure that nothing one of our users does >> can compromise our security and work under the constraint that I have >> no control over, and in some cases not even any access to, our >> individual users' machines. Theorem: There is exactly one way to attain Woods' Goal: fully disconnect all individual users' machines from the internet. Proof: Case 1. There exists some port on which you allow any incoming network connections to user machines. If so I (adversary) write a daemon on my machine that accepts arbitrary commands from that port and runs them as root on my machine. Then any outside hacker can get in, can enable packet sniffing on your net, etc. Comment: It is not sufficient for you to allow some subset of ports on which I can connect and attempt to verify that the higher-level protocol on that port is correct (e.g., SMTP only on port 25, X on port 6001) because I can encapsulate my commands in legal SMTP or X packets. (I have assumed your firewall permits a non-trivial higher-level protocol to run on this port, e.g., telnet, ftp, http, X, smtp, etc.) Case 2. You disallow all (nontrivial) incoming connections, but you allow outgoing connections on any port (again, expecting that users run a non-trivial protocol like ftp or X.) Then I write program on my machine (M) that opens a connection on this port (encapsulating to disguise these packets as legitimate higher-level protocol) to an external machine (E) that I can access. I write a program on machine E that accepts connections from anywhere in the internet, and forwards any data (encapsulated) from any of them to my program on M. My program on M runs these commands in a shell as root. Again, anyone on the internet can run arbitrary programs on an internal machine (M). Therefore, if you allow either any incoming or any outgoing connections, an internal user can give access to hackers. Thus, the only strategy that achieves your goal is to disconnect. Another comment: even if your users are not malicious adversaries deliberately opening up your network, as I assumed they are in the proof, they might download and run trojan horses that disable security in the same way. Do you buy this argument? If so, I would augment your statement: [Your security policy] depends on what you are trying to protect and how sophisticated your users are. with: If you connect your users' machines to the internet, you must trust your users (to some degree) to enforce your security policy. So I reiterate my position: I agree you must prevent users from naively and accidentally defeating your efforts while trying to get legitimate work done (e.g., "xhost +"). However, you fundamentally cannot keep your users from making circumvention of your policies possible. Therefore, there's some cutoff point at which you give up: you accept some risk no matter what. Whether or not you accept the risk of users building their own X servers is an open question, but your reasoning >> >Do you feel you need to feel responsible for >> > the security of a user who does things like building his own X server? >> >> Yes, I do, if a hacker can use this X server to get on to that users >> system and attack some of the systems I want to protect from there. leads to concluding that you must disconnect your user's machines from the internet, since you cannot prevent users from creating things that hackers use to attack a system you want to protect. I hope this discussion isn't too "academic" for this list. I think it's an interesting topic, and look forward to any responses to this message. 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 Wed Oct 19 11:30:44 1994 X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 19 Oct 94 12:19:38 PDT From: "Heather J. Reid" Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Dial-in security I am curious what people are doing to secure dial-in lines to the campus network. We have just put a modem pool in place (access through a Xyplex terminal server from which you can telnet to hosts on campus) and now want to pur some security in front of it. Are people using home-grown security facilities? DCE? some form of dial-back?? - ------------------------------------- Name: Heather J. Reid E-mail: hreid@elmer.harvard.edu (Heather J. Reid) Date: 10/18/94 Time: 10:14:48 This message was sent by Chameleon - ------------------------------------- -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 11:58:50 1994 Posted-Date: Wed, 19 Oct 1994 12:52:37 -0400 Date: Wed, 19 Oct 1994 12:52:37 -0400 From: millar@pobox.upenn.edu (Dave Millar) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Secure Lab Access (Was Re: Cameras in Labs) Dave Hess writes: >The ISI "Tunnel" works along these principals. Don't know if it is freely >available or not. Annette DeSchon is one of the authors >on the 1993 paper I have about it. Thanks for the info, Dave. For those interested, the paper is available (in PostScript format) from URL: ftp://ftp.isi.edu/isi-pubs/isi-sr-93-358.ps Dave M. _________________________________________________ Dave Millar University Information Security Officer 3401 Walnut St., Suite 335B Philadelphia, PA 19104-6228 University of Pennsylvania For security matters: security@isc.upenn.edu (read by Data Admin. staff) Other matters: millar@pobox.upenn.edu voice: (215) 898-2172 fax: (215) 898-1729 For PGP 2.6 Public key: http://www.upenn.edu/security-privacy/ PGP Fingerprint: 28 FB 09 DC C7 96 C2 53 1A B8 BE 3B 73 32 46 4C -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 12:23:05 1994 Date: Wed, 19 Oct 94 12:59:35 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson, P.E. Information Security) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: secure X Kenneth J. Duda rites: >Theorem: There is exactly one way to attain Woods' Goal: fully >disconnect all individual users' machines from the internet. >Proof: > Case 1. There exists some port on which you allow any incoming > network connections to user machines... > Case 2. You disallow all (nontrivial) incoming connections, but you > allow outgoing connections on any port (again, expecting that > users run a non-trivial protocol like ftp or X.)... The fallacy here is that allowing a port connection through a firewall makes that connection available to *all* internal machines. In fact, even Cisco routers allow you to designate not only the port but the individual internal machines it may connect to. Further, it is possible for an active monitor to determine what those connections actually do. As a result, Inward/outward FTP can be limited to only those machines which are authorized to do so, have trained administrators, and which are periodically checked for proper authorization. For that matter, the same restriction can be extended to the outside sites: For instance, if you do not want your users FTPing in viral code from locations known to carry such, you might want to consider disallowing connection to NETCOM hosts. True, the only 100% protection is SPACKLE but IMHO with intelligent planning, the risk can be driven down into the noise with very little effort. First, review the literature. Second, inventory what you have. Third decide what is needed. Fourth, disallow anything else. Fifth, return to First. Warmly, Padgett -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 13:31:06 1994 In-Reply-To: <199410191549.IAA23574@Bump.Stanford.EDU>; from "Kenneth Duda" at Oct 19, 94 8:49 am X-Mailer: ELM [version 2.3 PL11] Date: Wed, 19 Oct 94 12:25:26 MDT From: woods@ncar.UCAR.EDU (Greg Woods) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: secure X? > I was specifically making assumptions about your security needs based > on being an academic institution Strictly speaking, we're *not* an academic institution. We're a *research* institution. As such, we have different needs from both universities and from commercial companies, but we're closer to the former than the latter. Our mission as a supercomputing facility for the atmospheric research community REQUIRES us to permit a certain level of access from the outside. Therefore, most solutions adopted by commercial companies will not work for us (and hence my interest in this mailing list). However, we also don't have 10,000 or so undergraduate students to worry about, and that differentiates us from most universities. We can afford to extend a little more trust to our internal users than most universities can. We also have some very large hacker targets here (CRAY supercomputers). We want to allow our users access to these, but keep the bad guys off. We have CRAY users that are both inside our network (physically located at our site) and also located at various universities and research institutions around the world. Therefore, "disconneting" will not achieve our goals. > >> I have to make sure that nothing one of our users does > >> can compromise our security This creates some confusion in Ken's mind that is at least partially my fault; I should phrase this more carefully as "nothing one of our users does can INADVERTENTLY compromise our security". I already said in my previous message that we trust our users not to DELIBERATELY damage our systems; this includes assuming they will not KNOWINGLY allow others to do so, either. I see a distinction between a user who types "xhost +" so that *they* won't run into "access denied" situations in the course of their work, and one who deliberately sets up a telnet server on an unrestricted port so that his hacker buddies can get in. We want to guard against the former, not the latter. The latter is an acceptable risk, the former is not. Allowing free access from the Internet to a user's workstation that is configured as shipped by the vendors is also not an acceptable risk. > Case 2. You disallow all (nontrivial) incoming connections, but you > allow outgoing connections on any port Basically, this is the plan. Any TCP packet that does not have the ESTABLISHED bit set or any UDP packet that is not bound for a specific port (e.g. DNS) will be blocked at the perimiter (the UDP problem has not been completely solved yet, but we're a ways from actually turning on any filters so we've still got time to think about this). That should permit unrestricted outbound connections while blocking anything inbound that we have not specifically decided to allow. All inbound connections will have to go through an authenticating gateway host using one-time passwords, with only specific exceptions permitted. > Therefore, if you allow either any incoming or any outgoing > connections, an internal user can give access to hackers. Not unless they are 1) a relatively sophisticated user; and 2) maliciously and deliberately subvert our security policy. We will, of course, need to be monitoring what goes in and out and looking for things like this, but again, we consider this an acceptable risk. > If you connect your users' machines to the internet, you must trust > your users (to some degree) to enforce your security policy. I do agree with this, and the "to some degree" is the key; I trust them to not DELIBERATELY SUBVERT our policy, except maybe to make things easier for themselves; I do *not* trust them to ACTIVELY ENFORCE it. I see a big difference between those two. > However, you fundamentally cannot keep your users from making > circumvention of your policies possible. Therefore, there's some > cutoff point at which you give up: you accept some risk no matter > what. On this I think we agree. It's a matter of determining what they are likely to do only to make things easier for themselves. I am assuming that they *will* do this, but that they will *not* go out of their way to provide access for unauthorized users. Our policy will be as effective as that assumption is accurate (in theory, anyway). - --Greg -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 14:36:02 1994 Date: Wed, 19 Oct 1994 15:30:18 -0400 From: *Hobbit* Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dial-in security doesnt xyplex support kerberos on their term servers in some way? [i.e. user logs in via modem, gets a tgt for other machines, or something] _H* -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 14:38:12 1994 In-Reply-To: <9410191427.AA12177@pobox.upenn.edu> from "Dave Millar" at Oct 19, 94 10:27:33 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=LATIN-1 Content-Transfer-Encoding: 8bit Content-Length: 1333 Date: Wed, 19 Oct 1994 20:32:20 +0100 (MET) From: saouli@math.ethz.ch Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Secure Lab Access (Was Re: Cameras in Labs) Hello, From what I ahve seen now, the approach is to grant access to "public" facilities to a backbone, I don't see the point in doing so. It lets any dumy to put a snifer on the pc (a floppy can contian so much stuff these days)and grab the whole trafic (including passwords and text strings). Separating a pc network from the "backbone" by using a bridge gives you a pretty good protection against wiretaping on the backbone. This is the same for dorm networks, they can be screened one way or antoher. or isntance an etherswitch as concentrator could protect pretty efficiently the privacy of the users. At the EPFL the problem was solved by using access control at the doors of the pc and macintosh labs, ad thereby did only grant access to students that has an academical need of the resource. Now for what is done on the network, it is another question. It is very hard to authenticate with precision anything in a "public" lab, and even if you had the best authentication you might have problems due to a poor knowedge of "computer usage behaviours". - --K. Saouli - -- 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 -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 15:47:19 1994 Organization: University of Illinois at Chicago - (312) 413-1258 In-Reply-To: Message of Wed, 19 Oct 94 12:19:38 PDT from Date: Wed, 19 Oct 94 13:56:32 CDT From: Bob Jackiewicz Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dial-in security On Wed, 19 Oct 94 12:19:38 PDT Heather J. Reid said: >I am curious what people are doing to secure dial-in lines to the campus >network. We have just put a modem pool in place (access through a Xyplex >terminal server from which you can telnet to hosts on campus) and now want >to pur some security in front of it. Are people using home-grown security >facilities? DCE? some form of dial-back?? We're using Cisco terminal servers, and we have enabled (on one) their TACACS authentication program. If a user provides a correct login/password pair, they are given full internet access. Otherwise, they don't even get onto the server. You can grant accesslevels, and restrict connections by IP, and all sorts of things. Hope this helps. Bob Jackiewicz [\] UIC Computer Center E-mail: bobj@uic.edu University of Illinois at Chicago Network Services You're throwing it all out the Windows! -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 15:57:49 1994 In-Reply-To: from "Heather J. Reid" at Oct 19, 94 12:19:38 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1507 Date: Wed, 19 Oct 1994 13:51:55 -0700 (PDT) From: Peter Van Epp Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dial-in security We are using Xlogics Annex3 terminal servers (although we looked hard at Xyplex because of the Kerberos capability). They come with the source to the host side of the authentication daemon and in the very latest release that supports callback to the authentication host on connection actions after login looks to be able to support full Kerberos, using tickets rather than just obtaining one as the Xplexes used to do (I don't know what the current Xyplex models do!). We have this set up so that your Unix ID and password are required (and logged) to get past the terminal server. We also use this mechanism to enforce restrictions on access (to faculty and staff) on certain modem banks and to charge for connect time on another modem bank. In all we have been very happy with the choice of the Annex3s. Peter Van Epp / Operations and Technical Support Simon Fraser University, Burnaby, B.C. Canada > > I am curious what people are doing to secure dial-in lines to the campus > network. We have just put a modem pool in place (access through a Xyplex > terminal server from which you can telnet to hosts on campus) and now want > to pur some security in front of it. Are people using home-grown security > facilities? DCE? some form of dial-back?? > ------------------------------------- > Name: Heather J. Reid > E-mail: hreid@elmer.harvard.edu (Heather J. Reid) > Date: 10/18/94 > Time: 10:14:48 > > This message was sent by Chameleon > ------------------------------------- > > > -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 16:42:28 1994 X-Authentication-Warning: dreez.sctc.com: Host localhost didn't use HELO protocol In-reply-to: Your message of "Wed, 19 Oct 1994 13:56:32 CDT." X-Mailer: exmh version 1.5phi 9/15/94 Date: Wed, 19 Oct 1994 16:36:05 -0500 From: endrizzi@sctc.com Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dial-in security I've never even seen a cisco so this might sound stupid. > If a user provides a correct login/password What kind of user, admin?? > pair, they are given full internet access. You make it sound like they log onto a host computer and can ftp/telnet/www out to the world from the router. Want to clarify. define "access" in terms of applications. > Otherwise, they don't even get > onto the server. Server.....Is this a Unix box or a Router with additional authentication software on it?? > You can grant accesslevels, and restrict connections by IP, > and all sorts of things. Hope this helps. grant and deny to who??? can you get access to other routers without loging in again. how does S/key,secure id fit into TACAS BTW, cisco won't tell me so i'm asking you. dumb and confused - --------------------------------------------------- "The above opinions where not mine but that of the American people." Michael J. Endrizzi;SCC; 2675 Long Lake Road Roseville, MN 55113;endrizzi@sctc.com - --------------------------------------------------- -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 17:08:45 1994 In-Reply-To: <199410192136.QAA27486@dreez.sctc.com> from "endrizzi@sctc.com" at Oct 19, 94 04:36:05 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 964 Date: Wed, 19 Oct 1994 15:02:34 -0700 (PDT) From: Peter Van Epp Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dial-in security Perhaps this line suggests why we now use Xylogics Annex3 terminal servers instead of the Cisco CS500 terminal server (I think that is the model anyway) that we started out with. We found that Cisco wanted to talk about routers routers routers not terminal servers anymore. I expect (given the reference to TACACS) the original person was also talking about Cisco terminal servers. If you are at the talking stage, I suggest trying annex-support@xylogics.com or your local Xylogics salesperson. Peter Van Epp / Operations and Technical Support Simon Fraser University, Burnaby, B.C. Canada > > BTW, cisco won't tell me so i'm asking you. > > dumb and confused > > --------------------------------------------------- > "The above opinions where not mine but that of the > American people." > Michael J. Endrizzi;SCC; 2675 Long Lake Road > Roseville, MN 55113;endrizzi@sctc.com > --------------------------------------------------- > > -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 19:23:50 1994 Mailer: Elm [revision: 70.85] Date: Thu, 20 Oct 94 9:49:20 CST From: Crusader Rabbit Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: unsubscribe unsubscribe academic-firewalls -------- From academic-firewalls-owner@net.tamu.edu Wed Oct 19 20:16:10 1994 Cc: academic-firewalls@net.tamu.edu In-Reply-To: <9410192051.AA20900@fraser.sfu.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII content-length: 1173 Date: Wed, 19 Oct 1994 22:08:13 -0300 (ADT) From: Steve MacLeod Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dial-in security On Wed, 19 Oct 1994, Peter Van Epp wrote: > We are using Xlogics Annex3 terminal servers (although we looked hard > at Xyplex because of the Kerberos capability). They come with the source to > the host side of the authentication daemon and in the very latest release that > supports callback to the authentication host on connection actions after login > looks to be able to support full Kerberos, using tickets rather than just > obtaining one as the Xplexes used to do (I don't know what the current Xyplex > models do!). We have this set up so that your Unix ID and password are required > (and logged) to get past the terminal server. We also use this mechanism to > enforce restrictions on access (to faculty and staff) on certain modem banks > and to charge for connect time on another modem bank. In all we have been > very happy with the choice of the Annex3s. > > Peter Van Epp / Operations and Technical Support > Simon Fraser University, Burnaby, B.C. Canada > Hi Peter, we are looking into the possibility of using our annex 3 to charge connect time usage with students, would you have any info (to share) on what you guys did to set this up? Thanks -------- From academic-firewalls-owner@net.tamu.edu Thu Oct 20 00:07:50 1994 Organization: University of Illinois at Chicago - (312) 413-1258 In-Reply-To: Message of Wed, 19 Oct 1994 16:36:05 -0500 from Date: Wed, 19 Oct 94 23:53:20 CDT From: Bob Jackiewicz Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dial-in security On Wed, 19 Oct 1994 16:36:05 -0500 said: >> If a user provides a correct login/password > >What kind of user, admin?? Any kind of user, specifically, those on a given Unix box. >> pair, they are given full internet access. > >You make it sound like they log onto a host computer >and can ftp/telnet/www out to the world from the router. >Want to clarify. define "access" in terms of applications. Well, in essence, yes. The terminal server talks to a process on Unix, via UDP, and that process validates the user's login and password. So, when you sign on to the terminal server, you're actually using a Unix box's authentication. >> Otherwise, they don't even get >> onto the server. > >Server.....Is this a Unix box or a Router with additional >authentication software on it?? No, on to the terminal server. You get three attempts at a correct userid and password pair. The terminal server then hangs up on you if you fail 3 times. >> You can grant accesslevels, and restrict connections by IP, >> and all sorts of things. Hope this helps. > >grant and deny to who??? can you get access to other routers >without loging in again. Once you're on the terminal server, your 'access level' is set. The admin of the terminal server (TS) creates a mask of IP numbers to which one may connect. When you're at the TS prompt, you can do things like telnet and SLIP. The process on the Unix box decides what your access level is, so you can code whatever you like in there. >how does S/key,secure id fit into TACAS Hmm, I'm not too familiar with S/key, but if it's a challenge type system, then you're stuck. If you can just give a one time password without prompts, then you should be able to hack the Unix process to accept the S/key authentication. The bummer is that I don't think that you can have a TS check more than one machine for a valid userid/password unless you code that into the Unix daemon. I guess the Unix daemon could do a kerberos lookup, but there is no native support of kerberos in the TS code, I don't think. Bob Jackiewicz [\] UIC Computer Center E-mail: bobj@uic.edu University of Illinois at Chicago Network Services Windows: A View to be Killed. -------- From academic-firewalls-owner@net.tamu.edu Thu Oct 20 08:24:22 1994 In-Reply-To: <199410200018.TAA05277@net.tamu.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 20 Oct 1994 08:18:44 -0500 (CDT) From: "Mr. Alex Irishkoff" Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: unsubscribe unsubscribe - ------------------------------------------------------------------------------ _/ _/_/_/_/ _/ _/ Alex Irishkoff (Cool Dude) _/ _/ _/ _/ Louisiana State University _/ _/_/_/_/ _/ _/ Baton Rouge, LA 70808 _/ _/ _/ _/ Email: zramaza@unix1.sncc.lsu.edu _/_/_/_/ _/_/_/_/ _/_/_/_/ Phone : (504) 763-6185 - ------------------------------------------------------------------------------ -------- From academic-firewalls-owner@net.tamu.edu Thu Oct 20 08:54:26 1994 X-Authentication-Warning: dreez.sctc.com: Host localhost didn't use HELO protocol In-reply-to: Your message of "Wed, 19 Oct 1994 23:53:20 CDT." X-Mailer: exmh version 1.5phi 9/15/94 Date: Thu, 20 Oct 1994 08:48:05 -0500 From: endrizzi@sctc.com Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Router Admin and TACACS (Was Dial-in security) I'm interested in how Cisco's TACACS protocol integrates into their terminal server and router products for the administrative interface. I've tried talking to Cisco, but they keep sending me product line information. Specifically: 1) Does it support One-Time Password schemes (s/key, secure id, etc)? 2) I've heard rumors that once an administrator logs into a router to perform maintenance, all other "visible" cisco routers can be administered with NO further authentication. True??? How??? 3) Is cisco moving to SNMPv2 with support for authentication services? 4) Your opinion on ease of administration, if security is an issue, recommendation for improvements. thanks, dreez - --------------------------------------------------- "The above opinions where not mine but that of the American people." Michael J. Endrizzi;SCC; 2675 Long Lake Road Roseville, MN 55113;endrizzi@sctc.com - --------------------------------------------------- -------- From academic-firewalls-owner@net.tamu.edu Thu Oct 20 10:00:28 1994 In-Reply-To: from "Steve MacLeod" at Oct 19, 94 10:08:13 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2078 Date: Thu, 20 Oct 1994 07:54:47 -0700 (PDT) From: Peter Van Epp Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dial-in security Sure, it depends on a somewhat strange policy for charging and a RDMS (Sybase) based charging mechanism. Probably code for all of this could be made available (the RDMS stuff belongs to our CS department). We have a charging system based on Sybase that is "charged up" by the user putting money in the account via the cashier's office. When they connect to the Annex, erpcd checks their Unix ID and password (using the NIS database) and then checks to see if they are on the charged modem pool by which ports they are on (I hope to modify this which is currently hard coded and ugly to use NIS netgroups for easier admin). If they are on a port that is charged for, then erpcd calls Sybase to see if they have money in their account, if not, then it sends an "access denied: account balance $ -xx.xx" (so the user knows how much money they would have to add to their account to get the balance positive again). If there is money in the account, the login proceeds as normal and the login is logged to syslog by erpcd. Once an hour a perl script examines the log file from the Annex and calculates the charges for anyone that has disconnected over the last hour (it may also charge users that have been connected for the hour as well, again this isn't my code). Since it doesn't ever disconnect anyone, the user can run up a negative balance. That is made to come out in the wash by having a policy that refunds from the account are not given, so if a student graduates with a negitive balance, he or she wins, if they have a positive balance, then that goes (somewhat) to balance the negative balances. I expect the rates (currently $.02 per minute in prime time and $.015 at night) are also adjusted to allow for the expected loss. If a log record is lost by syslog (or a terminal server crash), then the connection is free (to try and avoid having to deal with complaints of overcharging. Again there is likely a little slop built in to the rates to allow for this. Peter Van Epp / Operations and Technical Support Simon Fraser University, Burnaby, B.C. Canada -------- From academic-firewalls-owner@net.tamu.edu Thu Oct 20 10:27:36 1994 In-Reply-To: <9410201454.AA06372@fraser.sfu.ca> from "Peter Van Epp" at Oct 20, 94 07:54:47 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: 234 Date: Thu, 20 Oct 1994 08:21:55 -0700 (PDT) From: Peter Van Epp Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dial-in security Sorry about that last one, didn't read the headers carefully enough. Meant to send it only to the person requesting it not the list ... Peter Van Epp / Operations and Technical Support Simon Fraser University, Burnaby, B.C. Canada -------- From academic-firewalls-owner@net.tamu.edu Thu Oct 20 13:16:18 1994 In-Reply-To: <9410191419.AA10523@pobox.upenn.edu> from "Dave Millar" at Oct 19, 94 10:19:29 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: 1124 Date: Thu, 20 Oct 1994 14:10:26 -0400 (EDT) From: maf@net.ohio-state.edu Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Secure Lab Access (Was Re: Cameras in Labs) Dave Millar writes: >-Some kind of gateway between the lab and the backbone, which would require >authentication before going any further and would maintain logs of all >connections. This seems like the most promising alternative, though there >may be some concerns about throughput. Has anybody seen/done anything >like this? Firewalls seem to be based on restricting access to/from by >protocol(port)/address. Is there some way to configure a >gateway(firewall?) to require account/password authentication, and then >pass through any and all protocols, while logging all connections by >account? Anybody got any specifics? The KarlBridge software does this. It still hasn't been tested on a large scale though, and the timeout algorithm probably needs to be changed a bit. We plan to implement it in all the public labs at Ohio State real soon now. Throughput isn't a problem, a 386DX40 + 2 SMC Elite 16's can do real close to wire speed. ftp.net.ohio-state.edu:/pub/kbridge/kb_pub.zip. You'll need to use the kbc program 'tell' the bridge which src/dst/mask IP address to authenticate. - -- mark maf+@osu.edu -------- From academic-firewalls-owner@net.tamu.edu Thu Oct 20 15:06:50 1994 Date: Thu, 20 Oct 1994 15:59:58 -0400 From: rubin@woverines.bellcore.com (Avi Rubin) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Bellcore's Trusted Software Integrity System (Betsi) This is about a security service, although not exactly a firewall service, I figured most readers of the list would be interested. If you are familiar with Betsi, there is now a mosaic page for all of the messages to register and certify documents. http://info.bellcore.com/BETSI/betsi.html You can also get info. by sending mail to certify@bellcore.com with subject: help. ********************************************************************* Aviel D. Rubin Email: rubin@faline.bellcore.com Bellcore (MRE-2M354) ftp://thumper.bellcore.com/pub/rubin/rubin.html 445 South St. Morristown, NJ 07960 Voice: +1 201 829 4105 USA FAX: +1 201 829 2645 -------- From academic-firewalls-owner@net.tamu.edu Thu Oct 20 23:27:33 1994 Date: Fri, 21 Oct 1994 00:21:53 -0400 From: *Hobbit* Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dial-in security Now, that's interesting, and got me thinkin': syslog is pretty easy to spoof. What's to prevent a user from logging in, and after about five minutes, sending a forged "I logged out" message to erpcd or whatever, staying on for another nine hours, forging a "I just logged in" message, and then really logging out? _H* -------- From academic-firewalls-owner@net.tamu.edu Fri Oct 21 10:56:41 1994 Date: Fri, 21 Oct 94 08:50:55 PDT From: richard@wizard.ucs.sfu.ca (Richard Chycoski) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dial-in security > From: *Hobbit* > > Now, that's interesting, and got me thinkin': > > syslog is pretty easy to spoof. > > What's to prevent a user from logging in, and after about five minutes, > sending a forged "I logged out" message to erpcd or whatever, staying > on for another nine hours, forging a "I just logged in" message, and > then really logging out? > > _H* It's not perfect, but the Annexes put serial numbers on their log file messages. The users don't have access to the syslog files or the necessary Ethernet (we hope!), which makes it difficult to spoof the serial numbers. (I *didn't* say "impossible"!) - --- - - Richard Chycoski richard@sfu.ca (NeXT Mail OK) Senior Systems Consultant Academic Computing Services Simon Fraser University -------- From academic-firewalls-owner@net.tamu.edu Fri Oct 21 11:06:53 1994 In-Reply-To: <199410210421.AAA18313@asylum.sf.ca.us> from "*Hobbit*" at Oct 21, 94 00:21:53 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: 2339 Date: Fri, 21 Oct 1994 09:01:09 -0700 (PDT) From: Peter Van Epp Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dial-in security Perfectly correct (but not Zylogics nor erpcd's fault), there is that risk. Except that you would need to know the format of the log messages (easy) and the log sequence numbers of the messages from the annex which is less easy. This is mostly due to laziness on my part (or overwork/underpay depending on your point of view :-) ). A more likely concern is that syslog is also not reliable (being UDP), it drops log messages sometimes. The reason that I said this is my fault and not Zylogics nor erpcd's is that Zylogics points out that syslog is unreliable and that if you are going to do TS accounting from erpcd, they recommend either doing the logging to a file or modifying erpcd (since you have source) to write the login and logout records to a file on a secure machine. In our case, a breach would involve loss of revenue on our part, not an overcharge to the users, and the person responsible for the service is aware of this risk (and the cost of fixing it) and finds the level of risk acceptable. There is also a way of doing a gross crosscheck on the connect data that would probably turn up large scale fraud (and small scale fraud is currently considered not worth our time to address if indeed it is going on). We have taken a close look at the potential liabilities of this scheme and found them acceptable to us. If you were going to do something like this you should do the same. You may have gathered by now that I am quite impressed with the thought that has and is going it to work on the Annex software. While I haven't looked at the competition lately (I run on the "it isn't broke, why on earth would I want to fix it" school of thought), the latest release of Annex software has hooks that should allow (and I have heard rumors of a beta product) the Annex3s to support full Kerberos (possibly not encrypted session data, at least with full security though). Peter Van Epp / Operations and Technical Support Simon Fraser University, Burnaby, B.C. Canada > > Now, that's interesting, and got me thinkin': > > syslog is pretty easy to spoof. > > What's to prevent a user from logging in, and after about five minutes, > sending a forged "I logged out" message to erpcd or whatever, staying > on for another nine hours, forging a "I just logged in" message, and > then really logging out? > > _H* > -------- From academic-firewalls-owner@net.tamu.edu Fri Oct 21 19:56:43 1994 In-Reply-To: <9410181341.AA27599@uvs1.orl.mmc.com> X-Mailer: cppnews $Revision: 1.42 $ Organization: Nemesys Computer Consultants Ltd Lines: 30 Date: Sat, 22 Oct 94 00:25:49 GMT From: gvm@nemesys.com (Granville Moore) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Identification In article <9410181341.AA27599@uvs1.orl.mmc.com> you write: > >If we can get some kind of a handle as > >to either the machine involved, or in the case of the lab/novell > >workstations, who was accessing the machine and when, we hope to > >discourage / repremand abusers. > > With Novell you can get both - the little used "node id" is actually the > six byte unique ID of the NIC board in a PC or MAC. When we moved > to our new facility as part of the punch-down process all NIC ids were > recorded and are verified on each login. > > A number of months ago, we had an incident when something was repeatedly > banging on the supervisor account on a server across town. The log enabled > us to pinpoint the machine causing the problem and someone from security was > at the machine within five minutes. Word got around 8*). Although this might help to track down individuals in some cases, it can't be relied upon. Some boards implement this address in hardware, but some allow it to be changed by software. It certainly shouldn't be used as a secure method of authentication. Regards, Granville ======================================================================== Granville Moore gvm@nemesys.com Nemesys Computer Consultants Ltd System Security Specialists ========================================================================