Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: bzs@bu-cs.bu.edu (Barry Shein)
Newsgroups: comp.sys.sun
Subject: Re: Securing the Server
Keywords: Networks
Message-ID: <29073@bu-cs.BU.EDU>
Date: 21 Apr 89 22:23:31 GMT
References: <3086@udccvax1.acs.udel.EDU>
Sender: usenet@rice.edu
Organization: Boston U. Comp. Sci.
Lines: 28
Approved: Sun-Spots@rice.edu
Original-Date: 30 Mar 89 14:16:53 GMT
X-Sun-Spots-Digest: Volume 7, Issue 237, message 1 of 12

anderer@vax1.acs.udel.edu (David G Anderer):
>Problem: How do I prevent people from getting to the server via TELNET or
>RLOGIN?  There's no reason they should run jobs on the server, and a good
>one they shouldn't.

Well, you could put a message to that effect in /etc/motd on the server.
If you really want to prevent this you probably need to widen your scope
of what you're preventing them from doing, like using RSH or ON or using
the REXEC routines themselves.

If you want only root on the machine it's easy, just create an
/etc/nologin file with a message in it to that effect. Note that reboots
manipulate this file, may have to recreate from rc.local but that's no big
deal (echo 'No User Logins' > /etc/nologin).

You could set their shell path in the passwd file to a program which
checks who they are and what machine it's running on and either execs
their correct shell (could look at its argv[0]) or exits. If you use a
group to identify who can log in it's probably 20 lines of C code (tho you
probably want to be careful with testing what happens if ^C etc.  is sent,
probably just exits.)

-- 

	-Barry Shein, Software Tool & Die

There's nothing more terrifying to hardware vendors than
satisfied customers.