robjohn@OCDIS01.AF.MIL (Robert Johnson (CDC Contractor);CDC;) (05/27/90)
There are software products on the market which allow the system administrator to automate and control connections to other systems. We use a product that automates phone, network and direct connections, and restricts access to specified users or groups of users. The user picks the system they want from a menu, and the software handles the connection automatically. A few seconds later, they see the banner and login prompt of the system they wanted to use. There are two drawbacks. The administrator must set up access to new systems as needed, and must turn off other avenues such as tip, cu, and telnet. The product we use replaces telnet, but does not yet replace ftp. We have limited ftp access to a specified group of users, and we log their usage. At our site, the advantages far outweigh the disadvantages - simpler for the user, less user training/support, and a full audit trail of outbound connections made from our system. As background info, we have nearly 1500 users, about 550 people use the system each day, and several dozen use our system as a gateway to others. We plan on doubling this usage within a year. We have a Class A Internet address, a Class C Ethernet connection, outbound modems, and connection to several other systems through a base-wide broadband LAN. The product we use allows us to provide better service to our user community, reduce our training and support burden, and provide accountability and auditability. Bob Johnson, System Administrator Tinker Air Force Base, Oklahoma
robjohn@OCDIS01.AF.MIL (Robert Johnson (CDC Contractor);CDC;) (05/30/90)
In response to my recent posting about using a software product rather than a toll restrictor to control outbound connectivity, Andrew Heybey writes: > I'm curious as to what you mean by "turn off telnet". Of course, I don't > know what sort of system you're running and what sort of capabilities it > provides, but on a unix system, telnet is a user program that opens a > socket. If you remove the telnet program, all I have to do to get that > capability back is get the source to a telnet program from somewhere and > compile it in my home directory. Voila, I can telnet anywhere I want to. > I can do the same with ftp (in fact, I would write a crude ftp first so as > to be able to go get a better ftp and telnet from someplace else). Does > your system not allow unprivilidged users to open network connections? Are > you relying on nobody knowing how to write/compile/etc their own program to > use the net? Or does your system have some other mechanism for controlling > network access? Good question - nothing's ever as simple as it sounds, is it? By 'turn off', I mean we change permissions so only a trusted group of individuals can use it - not the user population at large. We protect telnet, ftp, cu, tip, and the compilers and debuggers this way. We also have daily reports showing who is using these functions. Rather than digress into a diatribe about system administration, I'll just say that our philosophy is not to deny service to our users, but to be fully accountable. Certain users need to use these compilers, debuggers and communications (other than we have provided by menu access) for valid purposes. We allow them to use them, but they must prove a valid need. And, they know that we regularly monitor these activities. Running the system this way provides full functionality for all users (based on a valid need), and yet maintains full accountability of our connectivity with other systems. Bob Johnson, System Administrator Tinker Air Force Base, Oklahoma
kmeyer@wrl.dec.com (Kraig Meyer) (06/02/90)
||Andrew Heybey wrote: ||> ...on a unix system, telnet is a user program that opens a ||> socket....Does your system not allow unprivilidged users to ||> open network connections? Are you relying on nobody knowing ||> how to write/compile/etc their own program to use the net? Or ||> does your system have some other mechanism for controlling ||> network access? In article <@ocdis01.af.mil> robjohn@OCDIS01.AF.MIL (Robert Johnson) writes: ||...By 'turn off', I mean we change permissions so only a trusted group ||of individuals can use it - not the user population at large. We protect ||telnet, ftp, cu, tip, and the compilers and debuggers this way. We also ||have daily reports showing who is using these functions...[this] maintains ||full accountability of our connectivity with other systems. Bob, I'm still curious whether the operating system you are using actually has a way of preventing a user from opening his or her own network connection. Under unix and many other OS, opening a network connection does not require any special privileges. On such a system, taking away a user's ability to run your copy of telnet, ftp, etc. does not take away a user's ability to telnet, ftp, etc. by using his or her own program. ***************************************************************************** Kraig Meyer kmeyer@wrl.dec.com On parole from the University of Southern California. All views expressed are my own and may or may not be the same as those of Digital Equipment Corp.
LYNCH@A.ISI.EDU (Dan Lynch) (06/07/90)
Kraig, You bring up a very cogent point> To wit, does a particular OS have the flexibility to control access on a per user basis to particular system resources. In the case of current interest you are interested in network access. In the late 70's I was associated with a computer service company (Tymshare) and we had users who cam in via Tymnet and users who cam in via Arpanet and we had to be able to permit/deny access on a per user basis to "the other network". We put th ehooks for this into our operating system, Tenex (the precursor of TOPS20). It was a simple hack to put in the OS. The only hair/pain was to then keep the list of permissions updated whenever we created a new user. IN fact, I have found that the mechanism part(s) of security and access control are very easy for the OS enforcement part. The huge and ugly part has to do with the administrative part of actually creating and modifying allthe lists of permissions on a per entity basis. I'm sure Unix could be hacked a bit to do the same as Tenex did many years ago. Dan -------
stev@VAX.FTP.COM (06/11/90)
>I'm sure Unix could be hacked a bit to do the same as Tenex did many >years ago. >Dan >------- assuming, ofcourse, that you have enough of the sources . . . .. stev