-------- From academic-firewalls-owner@net.tamu.edu Thu Aug 4 12:46:58 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id MAA23003 for academic-firewalls-m; Thu, 4 Aug 1994 12:46:25 -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 MAA22958 for ; Thu, 4 Aug 1994 12:46:09 -0500 Message-Id: <199408041746.LAA08456@ncar.ucar.EDU> Received: by ncar.ucar.EDU (NCAR-local/ NCAR Central Post Office 03/11/93) id LAA08456; Thu, 4 Aug 1994 11:46:07 -0600 In-Reply-To: <9407290036.AA11896@uvs1.orl.mmc.com>; from "A. Padgett Peterson, P.E. Information Security" at Jul 28, 94 8:36 pm X-Mailer: ELM [version 2.3 PL11] Date: Thu, 4 Aug 94 11:46:06 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 > Now the device can be emulated in software Yes, I know, but as I said before, this is not a good solution for us. We've got thousands of users all over the world that come in on MANY different platforms. Asking them all to install a specific piece of software in order to access us is completely out of the question. If they all had PC's, this would be great, but they don't. - --Greg . -------- From academic-firewalls-owner@net.tamu.edu Thu Aug 4 13:36:52 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id NAA23585 for academic-firewalls-m; Thu, 4 Aug 1994 13:36: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 NAA23540 for ; Thu, 4 Aug 1994 13:36:09 -0500 Received: by posaune.tamu.edu (NX5.67d/NX3.0M) id AA04443; Thu, 4 Aug 94 13:32:53 -0500 Message-Id: <9408041832.AA04443@posaune.tamu.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) Date: Thu, 4 Aug 94 13:32:53 -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: Dorms I'm curious about what other Universities do about networking in dorms. We are about to bring 8 dormitories onto the campus network and are worried about the resultant security problems. We are going to be using 10BaseT hubs with eavesdrop prevention which will help but we are wondering what other sites are doing about higher level issues. Are other sites doing any kind of firewalling between the dorms and the rest of campus and/or the Internet? Are you doing any intrusion detection on the traffic to and from the dorms? Also what protocols are you allowing in; IPX, AppleTalk, IP? And are you doing any filtering on them? 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 Aug 4 15:02:16 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id PAA24635 for academic-firewalls-m; Thu, 4 Aug 1994 15:01:52 -0500 Received: from VAXB.STEVENS-TECH.EDU (vaxb.stevens-tech.edu [155.246.1.3]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id PAA24586 for ; Thu, 4 Aug 1994 15:01:33 -0500 Received: from VAXC.STEVENS-TECH.EDU by VAXC.STEVENS-TECH.EDU (PMDF V4.2-11 #2500) id <01HFIKA4NWTC9YCQQX@VAXC.STEVENS-TECH.EDU>; Thu, 4 Aug 1994 15:56:40 EDT Message-id: <01HFIKA4OPR69YCQQX@VAXC.STEVENS-TECH.EDU> X-VMS-To: IN%"academic-firewalls@net.tamu.edu" X-VMS-Cc: KHOCKENB MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Date: Thu, 04 Aug 1994 15:56:39 -0400 (EDT) Precedence: bulk From: "Kurt M. Hockenbury" 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: Dorms From: Dave Hess : >Are other sites doing any kind of firewalling between the dorms and the >rest of campus and/or the Internet? Are you doing any intrusion detection >on the traffic to and from the dorms? Also what protocols are you allowing >in; IPX, AppleTalk, IP? And are you doing any filtering on them? I just joined the mailing list to find out the exact same information :-) The current situation we have at Stevens is quite simple - a filter prevents IP traffic from entering or leaving the dorms. IP traffic within the dorms can go between dorms but not out. IPX is also filtered out, due to older versions of Doom flooding the network with broadcast packets. The students use DECnet to talk to the VAXcluster in the computer center, which handles all their mail. (As an aside, I should mention that all the undergraduates are required to bring or buy a PC, and that we loan them network cards for the 4+ years of living in the dorm. Last year's freshman got 486dx2/66's). I've been pushing for funding for us to move the dorms to a routed, firewalled, limited-ip accessable network (letting them through to the rest of campus, but not the outside world). Since a number of the machines the students need to connect to do not speak DECnet, they are forced to log into the vax before telnetting out. I'd also like to set up a proxy-httpd, allowing the students WWW access from the dorms. Also, there is a growing number of IP-based students (running various unix flavours), who have no native DECnet capability. As a side effect of not letting IP traffic through to the rest of campus, we've been getting some of our dial-in lines tied up by dorm users who don't want to reboot to DOS just to check their email. I'd like to know what the situation is at other sites. -Kurt Hockenbury . -------- From academic-firewalls-owner@net.tamu.edu Thu Aug 4 18:09:14 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id SAA26082 for academic-firewalls-m; Thu, 4 Aug 1994 18:08:53 -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 SAA26038 for ; Thu, 4 Aug 1994 18:08:37 -0500 Received: (kjd@localhost) by Bump.Stanford.EDU (8.6.8/8.6.4) id QAA24779; Thu, 4 Aug 1994 16:08:06 -0700 Message-Id: <199408042308.QAA24779@Bump.Stanford.EDU> In-reply-to: "Kurt M. Hockenbury"'s message of Thu, 04 Aug 1994 15:56:39 -0400 (EDT) <01HFIKA4OPR69YCQQX@VAXC.STEVENS-TECH.EDU> Date: Thu, 4 Aug 1994 16:08:06 -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: Dorms >> The current situation we have at Stevens is quite simple - a filter >> prevents IP traffic from entering or leaving the dorms. IP traffic >> within the dorms can go between dorms but not out. IPX is also filtered >> out, due to older versions of Doom flooding the network with broadcast >> packets. ... >> I've been pushing for funding for us to move the dorms to a routed, >> firewalled, limited-ip accessable network (letting them through to the >> rest of campus, but not the outside world). Kurt, I don't understand the motivations for these policies, particularly with regards to IP. Are you trying to protect your students from the "wild Internet", or vice versa? :-) In all seriousness, What do you see as the tradeoff between risks and services here? At Stanford, we currently go ahead and route all IP directly between the dorms and the Internet. I don't know the motivation behind this policy either; pehaps we ought to attempt to protect students' machines better than this. The situation is the same at M.I.T., as I understand it. Does anyone have any insight into what might be an apporpriate security architecture for dormitories, or what principles ought to guide one in designing a security architecture? I believe the nature of administrative and academic boundaries within a university provides considerable guidance in figuring out how to secure their machines. With dormitories, the situation is a little different --- I don't necessarily trust the guy down the hall any more than people in other dorms, or dorms at other universities for that matter. Perhaps monitoring and logging is more useful than filtering here? Any thoughts? 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 Aug 4 19:03:57 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id TAA26684 for academic-firewalls-m; Thu, 4 Aug 1994 19:03:33 -0500 Received: from kirk.Bond.edu.au (kirk.Bond.edu.au [131.244.1.1]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id TAA26637 for ; Thu, 4 Aug 1994 19:03:14 -0500 Received: from kirra.its.Bond.edu.au by kirk.Bond.edu.au using ESMTP (8.6.7) Received: from localhost by kirra.its.Bond.edu.au (8.6.4) id KAA26565; Fri, 5 Aug 1994 10:07:27 +1000 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 5 Aug 1994 10:07:25 +1000 (EST) Precedence: bulk From: Paul Pyyvaara 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: Dorms On Fri, 5 Aug 1994, Huw Davies wrote: > Well, network into our Colleges (Autralian for Dorms :-) is at an early > stage. About 18 months ago the University network was extended to each > college and then they were allowed to do what they liked internally. In > Menzies (the college I'm associated with) we asked our students what > they'd like (strange concept, I know :-) and we've installed two Mac labs > (each with 12 systems) one of which is connected to the University > network. Due to the subnet they are in, they only have direct IP access > to the Univeristy and need to go through another level of authentication > to get out to the 'real' world. Here at Bond we are a little more restrictive in what we allow - asyncronous connections from IBM clones to terminal servers only - requires that the users have a valid account on one of our UNIX systems and cannot sniff the ethernet for other user's passwords, and Appletalk access via Localtalk only. We do not allow direct telnet from any restricted nets (labs or residences) except to a our library host and student machines. We do allow unlimited FTP from the macs (do we really care if students fill their hard drives ;-) and access to our Web home page as well as the student Microsoft Mail server. From the macs and UNIX systems students can print only to the lab machines and those printers shared by other students (they cannot see into any other zones around campus. Cheers, Paul. _____ /\____\ /\ Paul Pyyvaara - paulp@Bond.edu.au / / ___ \_____ _____ _____/ /\ http://Bond.edu.au/People/paulp.html / / /_\/ /\____\ /\____\ /\____\/ / / / ___ ; Thu, 4 Aug 1994 20:46:15 -0500 Received: by hermes.oit.unc.edu (4.1/TAS/11-16-88) id AA20764; Thu, 4 Aug 94 21:46:12 EDT Message-Id: <9408050146.AA20764@hermes.oit.unc.edu> Cc: kjd@cs.stanford.edu In-Reply-To: <199408042308.QAA24779@Bump.Stanford.EDU>; from "Kenneth Duda" at Aug 4, 94 4:08 pm X-Mailer: ELM [version 2.3 PL11] Date: Thu, 4 Aug 94 21:46:09 EDT Precedence: bulk From: Shava Nerad Averett 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: Dorms > At Stanford, we currently go ahead and route all IP directly between > the dorms and the Internet. I don't know the motivation behind this > policy either; pehaps we ought to attempt to protect students' > machines better than this. The situation is the same at M.I.T., as I > understand it. Do you use some form of network authentication (e.g. kerberos?) We are investigating the least restrictive way to firewall our student labs from the outside Internet to protect the Internet. We have already had a PC in an unproctored dorm lab used to break into a machine in France. The PCs are running ODI packet drivers and telnet. We are currently looking at blocking telnet from the labs to any machine off campus. If they want to get off campus (with telnet at well known ports) they would have to log in (and therefore be authenticated) at one of the central or departmental servers. Otherwise, in theory, anyone could walk in off the street (the dorms are locked, but I think you know how easy it is for anyone to get in...) and use our pc's to attack any system anywhere. I find it embarassing when I get email from CERT (no offense, CERTfolk!), and I feel like I've been littering on the information highway, or something...;) So, we're trying to fix it, by firewalling the unauthenticated labs off from the net for telnet, while still allowing client gopher and web traffic. It's not perfect -- there are ways to still get out if you are determined enough, by booting off a floppy or what have you. But it is a deterrant. I hope. Am I whistling in the dark? ;) Shava Nerad Averett Networking Systems University of North Carolina shava@unc.edu . -------- From academic-firewalls-owner@net.tamu.edu Thu Aug 4 21:06:46 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id SAA26391 for academic-firewalls-m; Thu, 4 Aug 1994 18:23:51 -0500 Received: from Slapshot.Stanford.EDU (schemers@Slapshot.Stanford.EDU [36.21.0.12]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id SAA26346 for ; Thu, 4 Aug 1994 18:23:32 -0500 Received: (from schemers@localhost) by Slapshot.Stanford.EDU (8.6.9/8.6.6) id QAA28226 for academic-firewalls@net.tamu.edu; Thu, 4 Aug 1994 16:23:31 -0700 Message-Id: <9408041623.ZM28224@Slapshot.Stanford.EDU> In-Reply-To: Kenneth Duda "Dorms" (Aug 4, 4:08pm) References: <199408042308.QAA24779@Bump.Stanford.EDU> X-Mailer: Z-Mail (3.0.0 15dec93) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Date: Thu, 4 Aug 1994 16:23:30 -0700 Precedence: bulk From: "Roland J. Schemers III" 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: Dorms On Aug 4, 4:08pm, Kenneth Duda wrote: > Subject: Dorms > > > I don't understand the motivations for these policies, particularly > with regards to IP. Are you trying to protect your students from the > "wild Internet", or vice versa? :-) In all seriousness, What do you > see as the tradeoff between risks and services here? I think the obvious risk is any student sitting in his dorm room can easily sniff passwords of other students on the same subnet. We usually hear about this a few times a semester, and it probably happens more often than that. The majority of the students in the dorms (using Macs, etc) are probably logging into the public clusters, so one thing we are doing is installing kerberized telnetd on the public workstations. Then people can use NCSA telnet 2.6.x and get an authenticatd/encrypted session to the public workstations. Roland - -- Roland J. Schemers III | Networking Systems Authentication Services Programmer | 414 Sweet Hall +1 (415) 723-6740 Distributed Computing Operations | Stanford, CA 94305-3090 Stanford University | schemers@Slapshot.Stanford.EDU . -------- From academic-firewalls-owner@net.tamu.edu Thu Aug 4 21:10:07 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id SAA26492 for academic-firewalls-m; Thu, 4 Aug 1994 18:35:16 -0500 Received: from lucifer.latrobe.edu.au (lucifer.latrobe.edu.au [131.172.4.11]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id SAA26445 for ; Thu, 4 Aug 1994 18:34:52 -0500 Received: by lucifer.latrobe.edu.au (5.67a/DEC-Ultrix/4.3) id AA13246; Fri, 5 Aug 1994 09:34:43 +1000 Sender: Huw Davies Cc: Mark Kosten In-Reply-To: <199408042308.QAA24779@Bump.Stanford.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Date: Fri, 5 Aug 1994 09:34:42 +1000 (EST) Precedence: bulk From: Huw Davies 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: Dorms On Thu, 4 Aug 1994, Kenneth Duda wrote: > I don't understand the motivations for these policies, particularly > with regards to IP. Are you trying to protect your students from the > "wild Internet", or vice versa? :-) In all seriousness, What do you > see as the tradeoff between risks and services here? Well, network into our Colleges (Autralian for Dorms :-) is at an early stage. About 18 months ago the University network was extended to each college and then they were allowed to do what they liked internally. In Menzies (the college I'm associated with) we asked our students what they'd like (strange concept, I know :-) and we've installed two Mac labs (each with 12 systems) one of which is connected to the University network. Due to the subnet they are in, they only have direct IP access to the Univeristy and need to go through another level of authentication to get out to the 'real' world. One of the other colleges has installed either high-speed serial or ethernet to most rooms and the students with ethernet are 'directly' connected to the real world. Finances permitting, we will do something similar for a fair proportion of Menzies next year. Huw Davies | Huw.Davies@latrobe.edu.au Computing Services | Phone: +61 3 479 1500 Fax: +61 3 479 1999 La Trobe University | I own an Alfa to keep me poor in a monetary Melbourne Australia | sense, but rich in so many other ways . -------- From academic-firewalls-owner@net.tamu.edu Thu Aug 4 21:17:33 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id TAA27017 for academic-firewalls-m; Thu, 4 Aug 1994 19:22:34 -0500 Received: from fac.anu.edu.au (durras.anu.edu.au [150.203.22.8]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id TAA26969 for ; Thu, 4 Aug 1994 19:22:14 -0500 Received: from pretty.anu.edu.au.anu.edu.au by fac.anu.edu.au (4.1/SMI-4.0) id AA09112; Fri, 5 Aug 94 10:21:58 EST Message-Id: <9408050021.AA09112@fac.anu.edu.au> Cc: dgb900@durras.anu.edu.au, ivan@durras.anu.edu.au, emb900@netman Date: Fri, 5 Aug 94 10:21:58 EST Precedence: bulk From: dgb900@durras.anu.edu.au (David Baldwin) 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: Dorms > Are other sites doing any kind of firewalling between the dorms and the > rest of campus and/or the Internet? Are you doing any intrusion detection > on the traffic to and from the dorms? Also what protocols are you allowing > in; IPX, AppleTalk, IP? And are you doing any filtering on them? At the Australian National University all the 7 residences have been connected to the campus network for 5 years or more. This was primarily to service terminal and mac labs in the early days. Over the past two years all residences (bar one) have had premises cabling (category 5 UTP) installed for phones and data. About half now offer mac networking (PhoneNet), and 1 has had ethernet all this year, with another 2 intending to follow suit soon. No firewalls. We have restricted dial-in access to the subnets because students are setting up Linux boxes and accounts there are being used for mudding, etc, which is not tolerated on our dial-in. We are considering kerberos, etc, but have no installation of this as yet anywhere on campus, so we are lacking expertise somewhat. Any tips to good information on getting started? David. =====================================+=======================================+ David Baldwin | e-mail: David.Baldwin@anu.edu.au | Head, Faculties Computer Unit | phone: {intl+61+6+ | (06)} 249 5026 | Australian National University | FAX: {intl+61+6+ | (06)} 249 3992 | Canberra ACT 0200, AUSTRALIA +=======================================+ . -------- From academic-firewalls-owner@net.tamu.edu Thu Aug 4 22:24:34 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id WAA28736 for academic-firewalls-m; Thu, 4 Aug 1994 22:24:32 -0500 Received: from localhost (d1s8027@localhost) by net.tamu.edu (8.6.7/8.6.7) with SMTP id WAA28681 for ; Thu, 4 Aug 1994 22:21:28 -0500 Message-ID: <28680.776056887@net.tamu.edu> Date: Thu, 04 Aug 1994 22:21:27 -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: Digest version and archive The digest version of academic-firewalls is now available. To subscribe, just drop a line to 'majordomo@net.tamu.edu', with a line similar to subscribe academic-firewalls-digest [alternate-email-address] in the body of the message (not the subject); (if you use the alternate email address stuff, leave off the brackets... they just indicate it is optional). Also, an archive of the list is available for anonymous FTP from net.tamu.edu:/pub/security/lists/academic-firewalls It is/will be updated once a week. 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 Aug 4 22:57:20 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id WAA29084 for academic-firewalls-m; Thu, 4 Aug 1994 22:57:18 -0500 Received: from babble.cob.ohio-state.edu (babble.cob.ohio-state.edu [128.146.109.13]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id WAA29021 for ; Thu, 4 Aug 1994 22:54:16 -0500 Received: from curiosity.cob.ohio-state.edu (curiosity [128.146.109.24]) by babble.cob.ohio-state.edu (8.6.9/8.6.9) with ESMTP id XAA13631 for ; Thu, 4 Aug 1994 23:54:03 -0400 Received: (from maf@localhost) by curiosity.cob.ohio-state.edu (8.6.9/8.6.9) id XAA01606 for academic-firewalls@net.tamu.edu; Thu, 4 Aug 1994 23:54:14 -0400 Message-Id: <199408050354.XAA01606@curiosity.cob.ohio-state.edu> In-Reply-To: <9408050146.AA20764@hermes.oit.unc.edu> from "Shava Nerad Averett" at Aug 4, 94 09:46:09 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: 2840 Date: Thu, 4 Aug 1994 23:54:13 -0400 (EDT) Precedence: bulk From: maf@cob.ohio-state.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: Dorms >We are investigating the least restrictive way to firewall our student >labs from the outside Internet to protect the Internet. We have already >had a PC in an unproctored dorm lab used to break into a machine in France. >The PCs are running ODI packet drivers and telnet. We are currently >looking at blocking telnet from the labs to any machine off campus. If >they want to get off campus (with telnet at well known ports) they would >have to log in (and therefore be authenticated) at one of the central >or departmental servers. At Ohio State, public labs have TCP port 25 blocked for our class B networks, and everything else passed. Access outside of OSU is limited to finger, gopher, wais, www, and phonebook. This is done with a filtering bridge (KarlBridge) in every lab. Since the filtering bridges are located between the public lab, and our backbone there's really no way for anyone to break out. Unfortunately, many people are complaining that this is too restrictive. Having users connect to a host inside OSU to authenticate themselves and then telnet/ftp/etc out, not only places a large load on the server they are using to bounce off of, but also makes it impossible to use clients like Fetch and Mosaic on their local PeeCee or Mac. By next quarter, public lab machines will be able to telnet to an authentication server, authenticate themselves, and the server will use their IP address to lookup the filtering bridge IP address of the lab they are in. The authentication server then sends the bridge an "okay, let this host have access to the Internet request." This dynamic filter stays active until they either logout through the authentication server, or their IP address is inactive for some timeout value. We've tested this in the lab, but not in production yet....Additional precautions will also be taken, for example the bridge will send a Syslog message and/or SNMP-Trap on duplicate IP addresses (an IP address that has been used by more than a single Ethernet address). We're looking into upgrading the hubs in labs that do not have the eavesdrop protection/1 MAC address per port feature. As a side note, a few weeks ago due to some miscommunication, the SMTP port was opened all hosts instead of limiting it to the well-known campus mail server. Not too long afterwards we had someone trying to use our mail->news gateway with a From: line of Santa Claus.... >Otherwise, in theory, anyone could walk in off the street (the dorms are >locked, but I think you know how easy it is for anyone to get in...) and >use our pc's to attack any system anywhere. I find it embarassing when I >get email from CERT (no offense, CERTfolk!), and I feel like I've been >littering on the information highway, or something...;) Atleast CERT isn't the New York Times... - -- mark maf+@osu.edu -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 07:10:05 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id HAA02363 for academic-firewalls-m; Fri, 5 Aug 1994 07:09:59 -0500 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id HAA02301 for ; Fri, 5 Aug 1994 07:06:40 -0500 Received: from demon.demon.co.uk by post.demon.co.uk id af04664; 5 Aug 94 12:44 GMT-60:00 Received: from cellnet.co.uk by demon.demon.co.uk id aa23170; 5 Aug 94 12:40 BST Received: from ford with uucp; Fri, 5 Aug 94 01:48:08 Received: from zaphod by ford.gbnet.org; Fri, 5 Aug 94 01:48:08 BST Cc: net.tamu.edu!academic-firewalls@cellnet.co.uk Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Date: Fri, 5 Aug 1994 01:49:12 BST Precedence: bulk From: steve@gbnet.org 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: Dorms On Thu, 4 Aug 94 13:32:53 -0500 Dave Hess wrote: > I'm curious about what other Universities do about networking in dorms. We > are about to bring 8 dormitories onto the campus network and are worried > about the resultant security problems. We are going to be using 10BaseT > hubs with eavesdrop prevention which will help but we are wondering what > other sites are doing about higher level issues. > Are other sites doing any kind of firewalling between the dorms and the > rest of campus and/or the Internet? Are you doing any intrusion detection > on the traffic to and from the dorms? Also what protocols are you allowing > in; IPX, AppleTalk, IP? And are you doing any filtering on them? At Ohio State they are putting KarlBridge's everywhere and [securely] filter between their FDDI ring based on Cisco's and entrances to buildings/labs etc. Regards Steve -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 07:41:26 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id HAA02917 for academic-firewalls-m; Fri, 5 Aug 1994 07:41:24 -0500 Received: from nodemgmt.acs.jmu.edu (nodemgmt.acs.jmu.edu [134.126.70.210]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id HAA02824 for ; Fri, 5 Aug 1994 07:38:17 -0500 Message-Id: <199408051238.HAA02824@net.tamu.edu> Received: by nodemgmt.acs.jmu.edu (1.37.109.8/16.2) id AA08909; Fri, 5 Aug 1994 08:31:01 -0400 Date: Fri, 5 Aug 1994 08:31:01 -0400 Precedence: bulk From: gary flynn 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: Dorms We're getting ready to do the same thing. We are also using hubs with eavesdrop protection. The hubs also send an SNMP trap upon detection of a changed ethernet address. We are currently allowing the dorms direct Internet access as the machines (and their MAC and IP addresses) are assigned to a particular individual. We did this last year for 24 students in our pilot project and it worked very well. Of course, we're going to watch closely ;-). There are no firewalls or filters at this time except that dorm IP subnets are blocked from sensitive areas on campus. We are not offering anything but TCP based services. The students would love to be able to use our Netware based lab software but the software agreements say only University owned machines can use the software so we can't offer that service. Pity. Our public labs are assigned subnets that aren't allowed direct Internet access but I think this is going to change. Too many tools are out there that make the Internet a valuable and attractive resource to the students. Gary Flynn Telecommunications Network Supervisor James Madison University > I'm curious about what other Universities do about networking in dorms. We > are about to bring 8 dormitories onto the campus network and are worried > about the resultant security problems. We are going to be using 10BaseT > hubs with eavesdrop prevention which will help but we are wondering what > other sites are doing about higher level issues. > Are other sites doing any kind of firewalling between the dorms and the > rest of campus and/or the Internet? Are you doing any intrusion detection > on the traffic to and from the dorms? Also what protocols are you allowing > in; IPX, AppleTalk, IP? And are you doing any filtering on them? > Dave -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 07:58:02 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id HAA03046 for academic-firewalls-m; Fri, 5 Aug 1994 07:58:00 -0500 Received: from icm1.icp.net (icm1.icp.net [192.94.207.66]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id HAA02992 for ; Fri, 5 Aug 1994 07:54:56 -0500 Received: from melita.melita.com ([192.68.22.2]) by icm1.icp.net (8.6.9/8.6.9) with SMTP id IAA27177 for ; Fri, 5 Aug 1994 08:54:54 -0400 Received: from [192.68.20.43] by melita.melita.com id aa28314; 5 Aug 94 8:54 EDT Received: by melupl.rd.melatl.com (AIX 3.2/UCB 5.64/4.03) id AA99028; Fri, 5 Aug 1994 08:53:41 -0400 Message-Id: <9408051253.AA99028@melupl.rd.melatl.com> In-Reply-To: <199408051238.HAA02824@net.tamu.edu> from "gary flynn" at Aug 5, 94 08:31:01 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: 723 Date: Fri, 5 Aug 1994 08:53:40 -0400 (EDT) Precedence: bulk From: davek@melita.melita.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: Dorms gary flynn writes ... > We are currently allowing the dorms direct Internet access [...] > Gary Flynn > Telecommunications Network Supervisor > James Madison University I'm a JMU alum (Computer Science '85) and I am interested in hearing what JMU is doing now. In which dorms are you allowing direct Internet access? I lived in Spotswood for a year and a half. Who is heading up the Math/CS department now? Is Diane Spresser (the department head when I was there) still there? Dr. Reynolds? John Fairfield? Who is the Academic Computing Services manager now? - -- | Dave Kennedy (davek@melita.com) Voice: 404-409-4575 | | UUCP: emory!melupl!davek Whois: DK87 | -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 08:10:42 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id IAA03245 for academic-firewalls-m; Fri, 5 Aug 1994 08:10:39 -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 IAA03143 for ; Fri, 5 Aug 1994 08:07:34 -0500 Received: by hawksbill.sprintmrn.com (5.65/1.34) id AA16074; Fri, 5 Aug 94 09:10:11 -0500 Message-Id: <9408051410.AA16074@hawksbill.sprintmrn.com> Cc: academic-firewalls@net.tamu.edu In-Reply-To: <9408051253.AA99028@melupl.rd.melatl.com> from "davek@melita.melita.com" at Aug 5, 94 08:53:40 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 820 Date: Fri, 5 Aug 1994 09:10:11 -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: Personal Mail (was: Re: Dorms) > > I'm a JMU alum (Computer Science '85) and I am interested in hearing > what JMU is doing now. In which dorms are you allowing direct > Internet access? I lived in Spotswood for a year and a half. > > Who is heading up the Math/CS department now? Is Diane Spresser (the > department head when I was there) still there? Dr. Reynolds? John > Fairfield? Who is the Academic Computing Services manager now? > That's swell, but can you keep the personal chit-chat off of the list and confined to private e-mail? Thanks, _______________________________________________________________________________ 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 Fri Aug 5 08:18:28 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id IAA03639 for academic-firewalls-m; Fri, 5 Aug 1994 08:18:26 -0500 Received: from bootes.cus.cam.ac.uk (root@bootes.cus.cam.ac.uk [131.111.8.1]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id IAA03451 for ; Fri, 5 Aug 1994 08:15:19 -0500 Received: from grus.cus.cam.ac.uk [131.111.8.3] (TAP id = root) by bootes.cus.cam.ac.uk with smtp (Smail-3.1.28.1 #176) id m0qWP75-000BzlC; Fri, 5 Aug 94 14:15 BST Received: by grus.cus.cam.ac.uk (Smail-3.1.28.1 #176) id m0qWP74-0007aoC; Fri, 5 Aug 94 14:15 BST Message-Id: In-reply-to: Your message of "Fri, 05 Aug 1994 08:31:01 EDT." <199408051238.HAA02824@net.tamu.edu> Date: Fri, 05 Aug 1994 14:15:05 +0100 Precedence: bulk From: Bob Dowling 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: Dorms gary flynn said ... > We are also using hubs > with eavesdrop protection. OK, I'm probably going to look a fool for asking this, but I'd rather be a fool for asking silly questions than for not asking sensible ones. Just what is a hub with eavesdrop protection? How does it block attacks from one student putting his/her PC/Mac/Unix box in promiscuous mode? How much do they cost relative to more basic hubs? - -------- Bob Dowling: UNIX Support, University of Cambridge Computing Service, rjd4@ucs.cam.ac.uk New Museums Site, Pembroke Street, +44 223 334728 Cambridge, UK. CB2 3QG. -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 08:46:02 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id IAA04044 for academic-firewalls-m; Fri, 5 Aug 1994 08:46:00 -0500 Received: from oxmail.ox.ac.uk (oxmail.ox.ac.uk [129.67.1.1]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id IAA03974 for ; Fri, 5 Aug 1994 08:42:45 -0500 Received: from aisunsa.offices.ox.ac.uk by oxmail.ox.ac.uk with SMTP (PP) id <12727-0@oxmail.ox.ac.uk>; Fri, 5 Aug 1994 14:42:15 +0100 Received: from UNIVERSITY_OFFICES_NSA/MAILQUEUE by aisunsa.offices.ox.ac.uk (Mercury 1.12); Fri, 5 Aug 94 14:42:15 GMT+0 Received: from MAILQUEUE by UNIVERSITY_OFFICES_NSA (Mercury 1.12); Fri, 5 Aug 94 14:41:45 GMT+0 Organization: University of Oxford Priority: normal X-mailer: Pegasus Mail v3.1 (R1a) Message-ID: Date: Fri, 5 Aug 1994 14:41:44 GMT0BST Precedence: bulk From: Mark Walters 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: Dorms > OK, I'm probably going to look a fool for asking this, but I'd rather be > a fool for asking silly questions than for not asking sensible ones. > > Just what is a hub with eavesdrop protection? I've used 3Com hubs (ECS series) and they have a thing called LAN Security Architecture (LSA) which provides a couple of security enhancements. When used in a structured 10BaseT LAN with the appropriate management card in the hub the MAC address of the device on each port is learnt and stored by the hub. You can then use the Disconnect Unknown Device (DUD) and Need To Know (NTK) features; DUD - if the hub has learnt a MAC address for a port and a different one appears the port can be disabled and/or a warning sent to a management station. The learning can be automatic - the first device on that port, or entered manually via the hub control panel. NTK - once a MAC address is learnt all traffic going out of a port is corrupted UNLESS it has a destination address equal to the device on that port. > How does it block attacks from one student putting his/her > PC/Mac/Unix box in promiscuous mode? Even if they can grab all the packets going past the only ones that make sense are the ones addressed to them. I believe the data portion of the packet is just overwritten with rubbish by the hub (?). The 3Com hubs can be configured to allow broadcasts through, although they don't by default which can make life fun! I seem to recall some mention of a hub that would learn up to 4 addresses for each port but I can't remember the manufacturer. > How much do they cost relative to more basic hubs? I'm not sure I'm afraid but I don't think they're that much more, they used to be but the price margin between the vanilla and the secure verions has narrowed. Let me know if you want any more details. Mark ==================================================================== Mark Walters | Mark.Walters@university-offices.oxford.ac.uk Network Administrator | University Offices | Compuserve 100010,1511 Wellington Square | Tel: +44 (0)865 270246 Oxford OX1 2JD | FAX: +44 (0)865 270708 ==================================================================== PGP key fingerprint C5 05 C9 DF 0A D6 8C 08 50 CE B7 9F 52 36 2E 31 -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 09:25:58 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id JAA04909 for academic-firewalls-m; Fri, 5 Aug 1994 09:25:55 -0500 Received: from nodemgmt.acs.jmu.edu (nodemgmt.acs.jmu.edu [134.126.70.210]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id JAA04819 for ; Fri, 5 Aug 1994 09:22:51 -0500 Message-Id: <199408051422.JAA04819@net.tamu.edu> Received: by nodemgmt.acs.jmu.edu (1.37.109.8/16.2) id AA09963; Fri, 5 Aug 1994 10:15:32 -0400 Date: Fri, 5 Aug 1994 10:15:32 -0400 Precedence: bulk From: gary flynn 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: Dorms The hubs learn the MAC address attached to the port and don't let any other unicast packets reach that port unscrambled. You can set it up a number of ways depending upon your requirements. They can learn addresses or you can assign them. They can disable the port if the address changes, send an SNMP trap, or just ignore it. On our HP AdvanceStack hubs, the feature is part of the SNMP module. The stackable nature of the hubs allows multiple hubs to be managed from one hub that has an SNMP module but the security features (eavesdrop,etc) require the SNMP module to be installed in each hub for which you want the security features. Still, the HP AdvanceStack hubs are very price competitive. The AdvanceStack hubs with SNMP modules are less expensive than the old Ethertwist hubs. And I just read that HP cut the prices again. Gary Flynn James Madison University > OK, I'm probably going to look a fool for asking this, but I'd rather be > a fool for asking silly questions than for not asking sensible ones. > Just what is a hub with eavesdrop protection? How does it block attacks > from one student putting his/her PC/Mac/Unix box in promiscuous mode? -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 09:38:16 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id JAA05254 for academic-firewalls-m; Fri, 5 Aug 1994 09:38:15 -0500 Received: from flipper.pvv.unit.no (0@flipper.pvv.unit.no [129.241.36.200]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id JAA05121 for ; Fri, 5 Aug 1994 09:32:06 -0500 Received: (from agulbra@localhost) by flipper.pvv.unit.no (8.6.9/8.6.9) id QAA28215 for academic-firewalls@net.tamu.edu; Fri, 5 Aug 1994 16:31:51 +0200 Message-Id: <199408051431.QAA28215@flipper.pvv.unit.no> In-Reply-To: <199408051238.HAA02824@net.tamu.edu> from "gary flynn" at Aug 5, 94 08:31:01 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: 130 Date: Fri, 5 Aug 1994 16:31:50 +0200 (EET) Precedence: bulk From: Arnt Gulbrandsen 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: Dorms > We are not offering anything but TCP based services. Surely you mean IP. Or are you blocking out UDP (including DNS)? - --Arnt -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 10:20:02 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id KAA05987 for academic-firewalls-m; Fri, 5 Aug 1994 10:20:00 -0500 Received: from nodemgmt.acs.jmu.edu (nodemgmt.acs.jmu.edu [134.126.70.210]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id KAA05666 for ; Fri, 5 Aug 1994 10:13:56 -0500 Message-Id: <199408051513.KAA05666@net.tamu.edu> Received: by nodemgmt.acs.jmu.edu (1.37.109.8/16.2) id AA10521; Fri, 5 Aug 1994 11:06:41 -0400 Date: Fri, 5 Aug 1994 11:06:41 -0400 Precedence: bulk From: gary flynn 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: Dorms >> We are not offering anything but TCP based services. >Surely you mean IP. Or are you blocking out UDP (including DNS)? Yup, I meant IP. gary -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 10:25:16 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id KAA06157 for academic-firewalls-m; Fri, 5 Aug 1994 10:25:13 -0500 Received: from amdahl.com (amdahl.com [129.212.11.3]) by net.tamu.edu (8.6.7/8.6.7) with SMTP id KAA05969 for ; Fri, 5 Aug 1994 10:19:09 -0500 Received: by amdahl.com (/\==/\ Smail #25.33) id ; Fri, 5 Aug 94 08:19 PDT Received: from idontcare.eng.amdahl.com by cliffy.eng.amdahl.com (4.1/SMI-4.1) id AA12422; Fri, 5 Aug 94 08:18:01 PDT Message-Id: <9408051518.AA12422@cliffy.eng.amdahl.com> Date: Fri, 5 Aug 94 08:18:01 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: Re: Personal Mail (was: Re: Dorms) Could you keep admonitions to others to keep non-mailing list stuff off of the mailing-list off of the mailing-list? Sorry, I couldn't resist:) 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 Aug 5 10:29:16 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id KAA06243 for academic-firewalls-m; Fri, 5 Aug 1994 10:29:14 -0500 Received: from VAXA.STEVENS-TECH.EDU (vaxa.stevens-tech.edu [155.246.1.2]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id KAA06108 for ; Fri, 5 Aug 1994 10:23:07 -0500 Received: from VAXC.STEVENS-TECH.EDU by VAXC.STEVENS-TECH.EDU (PMDF V4.2-11 #2500) id <01HFJP5UQ7US9YCPRM@VAXC.STEVENS-TECH.EDU>; Fri, 5 Aug 1994 11:18:11 EDT Message-id: <01HFJP5UQ7UU9YCPRM@VAXC.STEVENS-TECH.EDU> X-VMS-To: IN%"academic-firewalls@net.tamu.edu" X-VMS-Cc: KHOCKENB MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Date: Fri, 05 Aug 1994 11:18:11 -0400 (EDT) Precedence: bulk From: "Kurt M. Hockenbury" 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: Dorms >I don't understand the motivations for these policies, particularly >with regards to IP. Are you trying to protect your students from the >"wild Internet", or vice versa? :-) In all seriousness, What do you >see as the tradeoff between risks and services here? Actually, it's a bit of both, plus a bit of protecting the rest of campus, plus a bit of bandwidth hoarding. 1) Protecting the "wild Internet" from the students: With our current hardware, it's an all-or-nothing situation for IP in the dorms. If we allowed all, we have no way of stopping ID and address spoofing, and no control (beyond the if-we-catch-you kind :-) or logging over outgoing connections. I'd hate to get a call from x.y.z.mil saying "We've got an intruder from 1.2.3.4 on at our site." and being unable to say anything other than "Gee, I don't know. Must be a student in the dorms. I'll turn on the sniffer to see if I can catch him." The way things are set up now, we have logs of who logged on when from where, who they connected to, etc. 2) Protecting the students from the "wild Internet": Last semester, we had a dozen students running Linux boxes in the dorms. This semester (when it starts) I'd guess the number will be closer to 40+. Some (most?) of those systems will be run by inexperienced people (I'm going to be giving sysadmin classes for them, though :-). Some of them, if we gave open access, would be likely to be hacked into, or have accounts on them given out to random people on the net who offer to "help fix your problem", etc. 3) Protecting the rest of campus Some of these machines, in addition to having normal security problems, will also have accounts given out to "a friend of my friend at SomeSchool.edu". I, for one, don't want to give intruders a local account for cracking from. We would get people laundering connections through us, people using these machines to attack other campus machines (ones that reject off-campus connections), and outsiders password sniffing on our net (as if locals weren't enough :-) 4) Bandwidth Hoarding: We are currently stuck on a 56KB link. (With luck, we may have a T1 by the end of the year.) Between news, mail, ftp, telnet, WWW, gopher, etc. it gets pretty crowded. I know for a fact that if we opened the dorms up, we would have several MUDs, pirate and X-rated ftp/fsp sites, and other noted bandwidth-eaters running within a month. Also, all dorm rooms have a phone in addition to a network connection. Any bets how long it would take before some enterprising young student decides to set himself up as a dial-in service provider? For that matter, I could see someone trying to set-up a public access unix site on our network. That wouldn't last long, but it would be yet another headache to deal with. As for the drawbacks, well there's one big one: we don't offer IP-based services from the dorms. :-( If you want to ftp something for your pc, you have to download it to the VAXcluster via ftp before using Pathworks NFT to transfer it to your harddrive. If you want to use Gopher or Lynx, you have to log onto the VAXcluster. You can't run Mosaic. The list goes on. That's why I want a firewall - to provide some of that to the dorms, while maintaining some bit of control and security. Maybe I'm overestimating the risks. But based on what I've seen in some of the academic departments on campus, it's better to overestimate than under. :-( Those who read this far, thanks. It ran longer than I expected. -Kurt Hockenbury -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 11:20:50 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id LAA07048 for academic-firewalls-m; Fri, 5 Aug 1994 11:20:48 -0500 Received: from gate.oxy.edu (paul@gate.oxy.edu [134.69.1.2]) by net.tamu.edu (8.6.7/8.6.7) with ESMTP id LAA06766 for ; Fri, 5 Aug 1994 11:14:45 -0500 Received: (from paul@localhost) by gate.oxy.edu (8.6.9/8.6.9) id JAA12879 for academic-firewalls@net.tamu.edu; Fri, 5 Aug 1994 09:14:40 -0700 Message-Id: <199408051614.JAA12879@gate.oxy.edu> Date: Fri, 5 Aug 1994 09:14:40 -0700 Precedence: bulk From: Paul Hubbard 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: Dorms > >OK, I'm probably going to look a fool for asking this, but I'd rather be >a fool for asking silly questions than for not asking sensible ones. > >Just what is a hub with eavesdrop protection? How does it block attacks >from one student putting his/her PC/Mac/Unix box in promiscuous mode? > >How much do they cost relative to more basic hubs? > We have some HP hubs like this. What they do is keep track of the hardware address of the computer plugged into each of the 10baseT ports. When a packet comes in, it looks at the dest from the ethernet frame header and figures out which (if any) port this packet should get sent to. If it decides that a given port shouldn't be given this packet, it just starts sending alternating 0 and 1 bits for the payload of the frame. The ethernet header always ends up being transmitted to all ports. Only the target machine will see the rest of the packet correctly. The rest of the machines plugged into the hub see garbage (and get a checksum error). Broadcast packets get transmitted to all machines. I hope I've explained how they work will enough. - -Paul Hubbard Occidental College -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 12:28:08 1994 Received: (from daemon@localhost) by net.tamu.edu (8.6.7/8.6.7) id MAA07793 for academic-firewalls-m; Fri, 5 Aug 1994 12:28:06 -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 MAA07727 for ; Fri, 5 Aug 1994 12:22:02 -0500 Received: from TCCSLR.DECnet MAIL11D_V3 by uvs1.orl.mmc.com (5.57/Ultrix3.0-C) id AA09990; Fri, 5 Aug 94 13:18:54 -0400 Message-Id: <9408051718.AA09990@uvs1.orl.mmc.com> Date: Fri, 5 Aug 94 13:18:54 -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: Dorms >On our HP AdvanceStack hubs, the feature is part of the SNMP >module. The stackable nature of the hubs allows multiple hubs >to be managed from one hub that has an SNMP module but the security >features (eavesdrop,etc) require the SNMP module to be installed in >each hub for which you want the security features. Saw some new hubs from 3Com that have this same feature - only packets addressed to a node are sent to it. The PCs can be set promiscuous all they want but they will still not receive anybody else's packets. Padgett -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 17:06:47 1994 In-Reply-To: <9408051718.AA09990@uvs1.orl.mmc.com> from "A. Padgett Peterson, P.E. Information Security" at Aug 5, 94 01:18:54 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 976 Date: Fri, 5 Aug 1994 17:02:06 -0500 (CDT) Precedence: bulk From: Dave J Duchscher Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: Dorms > > > >On our HP AdvanceStack hubs, the feature is part of the SNMP > >module. The stackable nature of the hubs allows multiple hubs > >to be managed from one hub that has an SNMP module but the security > >features (eavesdrop,etc) require the SNMP module to be installed in > >each hub for which you want the security features. > > Saw some new hubs from 3Com that have this same feature - only packets > addressed to a node are sent to it. The PCs can be set promiscuous > all they want but they will still not receive anybody else's packets. > > Padgett That would be the FMS-II stackable. It has all the standard features and only requires one of hubs to have the SNMP management card to implement the security features. Unfortunately, its not quite all there yet. I think the software and hardware will be sync up by Sept. 31. - -- David J Duchscher Texas A&M University Dave.Duchscher@net.tamu.edu CIS Network Project -------- From academic-firewalls-owner@net.tamu.edu Fri Aug 5 21:20:20 1994 id AA20149; Fri, 5 Aug 94 22:17:25 -0500 X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 3973 Date: Fri, 5 Aug 1994 22:17:24 -0500 (EST) Precedence: bulk From: paul@hawksbill.sprintmrn.com (Paul Ferguson) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: IRIX 5.2 Security Advisory (fwd) FYI - Forwarded message: > From firewalls-owner@GreatCircle.COM Fri Aug 5 22:02:44 1994 > From: lear@yeager.corp.sgi.com (Eliot Lear) > Message-Id: <9408051710.ZM11415@yeager.corp.sgi.com> > Date: Fri, 5 Aug 1994 17:10:15 -0700 > X-Mailer: Z-Mail (3.2a.627 27jun94 MediaMail) > To: firewalls@GreatCircle.COM > Subject: IRIX 5.2 Security Advisory > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Sender: Firewalls-Owner@GreatCircle.COM > Precedence: bulk > > Please distribute widely. I have no more information than is > discussed in the attached memo. > > From: "Customer Services Engineering" > Subject: IRIX 5.2 Security Advisory > Content-Type: text/plain; charset=us-ascii > Message-ID: > Sender: CustServEng@lucky.csd.sgi.com > Organization: Silicon Graphics, Inc. Mountain View, CA > Mime-Version: 1.0 > Date: Tue, 2 Aug 1994 23:07:08 GMT > > > Title: SGI Security Advisory for ALL IRIX 5.2 Systems > > Information Provided By: Miguel Sanchez > > Date: August 2, 1994 > > Document ID: FYI1994088 > > ============================================================================== > > SGI SECURITY ADVISORY > > > A potential vulnerability has been discovered in the IRIX 5.2 operating > system which would enable an unprivileged user to become an active > root user. This information is freely provided to the SGI user > community for their consideration and application. > > SGI engineering has investigated this issue and has the following > recommendation for neutralizing the exposure. It is HIGHLY > RECOMMENDED that the following steps be done on ALL SGI systems > running IRIX 5.2. The issue will be permanently corrected in a > future release of IRIX. > > > > > 1) Become the root user on the system. > > % /bin/su - > Password: > # > > 2) Remove the following subsystem of software. > > > # versions remove sgihelp.books.ViewerHelp > > ########################################################## > PLEASE NOTE: Removal of this subsystem will affect other > installed software that use the SGI Help system. After > the removal, certain help functions from within applications > will return non-fatal error messages about the missing > subsystem. > ########################################################## > > > 3) Return to previous user. > > # exit > % > > > > If it is suspected that some tampering has already occurred, the > standard security measures below can be taken to assess/limit the > scope of the violation. > > - Manually check the /etc/passwd file for new and/or changed > entries. Duplicating the passwd file from another trusted > SGI system is also possible. > > > - Have all users change passwords, inparticular priviledged > accounts. > > > - Manually investigate system critical files and applications > for possible tampering. The 'versions -m' command can be > used to list all files that have different checksum values > than those of the installed database. Any checksum > discrepancies could be cross checked with the checksum > of the same file on a trusted SGI system. > > > - Lastly, a complete clean and reload of software from > original distribution CDs can be done making sure to > do the above removal steps after the reload. > > > -- > > Customer Services Engineering (CSE) > > > > _______________________________________________________________________________ Paul Ferguson US Sprint Managed Network Engineering tel: 703.904.2437 Herndon, Virginia USA internet: paul@hawk.sprintmrn.com