[comp.unix.questions] Security from outside call-ins

root@scotty.UUCP (Don Cox) (07/18/88)

I am on a Sun 3/260 running SunOS3.5.  Plugged into Serial Port A
I have a Microcom AX/2400 modem.  Some of the users at my site are
so dedicated that they actually want to be able to do some work
while they are home by way of calling in on their modems! (Can
you believe it?)  

Here's the question:  They (the users) have told me of other
systems they have been on (I believe Vax's) where they were
prompted to enter a system password before they were even asked for
thier own.  This could be some cryptic type of combination of
letters and numbers, making it almost impossible for the average
hacker to break. Anyone have ideas on how I could incorporate this
into my passwd file, but only having it prompt those who are dialing
in on the modem?  This could get to be a real pain if they had to
respond to another password everytime they logged in from a work-
station here at work.  

Then, once the caller successfully types in the system password, 
they would still have to enter their own password.  Is such a
thing possible?  Thanks.
-- 
------------------------------------------------------------------
Don Cox :=)
UUCP: ..!rutgers!rochester!kodak!fedsys!scotty!dec
DISCLAIMER: The opinions expressed are mine and not of my employer. 

thomson@hub.toronto.edu (Brian Thomson) (07/19/88)

In article <262@scotty.UUCP> root@scotty.UUCP (Don Cox) writes:
>I am on a Sun 3/260 running SunOS3.5.  Plugged into Serial Port A
>I have a Microcom AX/2400 modem.
...
>Here's the question:  They (the users) have told me of other
>systems they have been on (I believe Vax's) where they were
>prompted to enter a system password before they were even asked for
>thier own.
>.... Anyone have ideas on how I could incorporate this
>into my passwd file, but only having it prompt those who are dialing
>in on the modem? 

You can define a new entry in /etc/gettytab that contains non-default
entries for the "lm" and "lo" strings.  Assuming that "2400-baud" the
entry that you currently use for port A, you might define

s|d2400|dial-2400:\
	:lm=\r\nSystem password\72 :lo=/usr/adm/dial-login:tc=2400-baud:

and in /etc/ttys select table entrty 's' for line 'ttya'.
You may want to mess around with other gettytab flags to, eg., turn off
echo.  See your online manual under 'gettytab' for details.

You must also supply a /usr/adm/dial-login program (or shell file) that
will compare its first argument with the system password.  Since this
password is probably known by every valid user on the system, I surmise
that it is not terribly sensitive and, in particular, that you do not
object if it is occasionally visible when people run 'ps' on your
system.

If this isn't exactly what you want, you can be more inventive.
The basic idea is that with gettytab you can have something other than
/bin/login run on specific lines.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

davidsen@steinmetz.ge.com (William E. Davidsen Jr) (07/19/88)

  I'm not sure that this adds a lot of security. If these users want to
be responsible users, they should have strong passwords of their own. Of
course you can have the .profile check the login terminal and ask for a
second password if the call is remote.

		SSSIACOSBIKB
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

trt@rti.UUCP (Thomas Truscott) (07/20/88)

>   I'm not sure that this adds a lot of security. If these users want to
> be responsible users, they should have strong passwords of their own. Of
> course you can have the .profile check the login terminal and ask for a
> second password if the call is remote.

Call-in security is important because it stops random attacks by outsiders.
Such attacks are rare, but are painful as they are hard to trace.
Fortunately, call-in security is easy to provide.
VMS has a nice implementation.  UNIX should have one too.

Where I work all call-in modems are connected to a dataswitch
that prompts "Account:" and gives the user a single chance
to enter one of the correct passwords.
This is difficult and boring for all but the most determined cracker.
(Local connections to the dataswitch have a more pleasant interface.)

This type of security protects the entire system, not any particular user.
A good operating system cracker can break security
once they get logged in as anyone at all.

Our "dataswitch defense" gives me peace of mind.
But then we are on the Internet, so I am just fooling myself!
	Tom Truscott

grzesiak@a3bee2.UUCP (John Grzesiak ) (07/29/88)

Another way you could do this is use a phony shell and the execl function
from the startup. Request a second password , hangup and call back the 
number associated with the password. It's a little involved but it is
absolute. A shell with an associated password file is all that would be
needed , along with a copy of cu to do dialing. If you don't know how to
go about tty handeling leave e-mail and I'll send you a few skeletons.
  -- John Grzesiak --
      at yale!spock!a3bee2!grzesiak