[comp.unix.xenix] Xenix dialin security

compata@cup.portal.com (05/06/88)

Under VMS, I am able to set an alarm which will log all login attempts
via a dial-in port.  (I can also set many other types of alarms.)  The
alarm does not depend upon the caller being successful at logging-in;
repeated bad attempts are also useful information.  I would like to
enable a similar facility for Xenix 386 2.2.  Does anyone know how this
can be done, or if it can be done?  Thanks in advance.  Please reply
via email; I'll post a collection of useful information (if there is any).

Dave Close, Compata, Arlington, Texas
email to compata@cup.portal.com or sun!cup.portal.com!compata
telex to 6295-5830

ag@portnoy.UUCP (Keith Gabryelski) (05/07/88)

! Email bounced !

In article <5153@cup.portal.com> compata@cup.portal.com writes:
>Under VMS, I am able to set an alarm which will log all login attempts
>via a dial-in port.  (I can also set many other types of alarms.)  The
>alarm does not depend upon the caller being successful at logging-in;
>repeated bad attempts are also useful information.  I would like to
>enable a similar facility for Xenix 386 2.2.  Does anyone know how this
>can be done, or if it can be done?

Sco Xenix does not support any type of login `log'.  The clean way
would be to hack /etc/login to log all login attemps.  This would take
time and money.

An optional way (read "It works, but only sorta") would be to add code
to the /etc/cshrc and /etc/profile to log every time they are invoked.
/etc/cshrc is sourced every time a login csh is invoked.  Likewise,
/etc/profile is sourced every time a login sh is invoked.

Sample code:

	who am i >> /etc/login.log

(oh, yes... /etc/login.log should be world writeable)

This code will work for /etc/profile and /etc/cshrc.

Disadvantages:

	o Not all login attemps are recorded.  Only successful logins
	  are recorded.

	o Only csh and sh logins are record.  Users with
	  other login shells that do not source one of the above
	  files will not show up in the log.  vsh (the visual shell)
	  and uucp transfer logins (/usr/lib/uucico/uucico) will not
	  be logged.

	o Since (in the above example) the log file must be world writeable,
	  it could be deleted if a user knew about it and wanted to hide
	  his login.  This could be taken care of by running a suid program
	  executed from /etc/profile or /etc/cshrc.

Hope this helps.

pax, Keith
-- 
[  Keith   ]  UUCP: {ucsd, cbosgd!crash, sdcsvax!crash, nosc!crash}!portnoy!ag
[Gabryelski]  INET: ag@portnoy.cts.com              ARPA: portnoy!ag@ucsd.arpa

kevinr@june.cs.washington.edu (Kevin Ross) (05/07/88)

In article <142@portnoy.UUCP> ag@portnoy.UUCP (Keith Gabryelski) writes:
>
>Sco Xenix does not support any type of login `log'.  

Xenix does have a user log, and logs all users. The log file is called
/etc/wtmp, and holds records of each login. It has the exact format of the
/etc/utmp file, and a program can be written using the data structures found
in #include <utmp.h>.

You can also display the wtmp file by using the who command:

who /etc/wtmp

which will read the wtmp file, and so you the login time and date for each
user.


If the file /etc/wtmp does not exists, then it will not keep a log. If you
don't have it, then you can just create one by cat /dev/null > /etc/wtmp.

On the flip side, the wtmp files can get enormous if you have a busy system.
If you don't need it, removing the file will stop the logging. 

Kevin

kevinr@june.cs.washington.edu

csch@tmpmbx.UUCP (Clemens Schrimpe) (05/09/88)

ag@portnoy.UUCP (Keith Gabryelski) writes:
{} Sco Xenix does not support any type of login `log'.  The clean way
{} would be to hack /etc/login to log all login attemps.  This would take
{} time and money.
{} 
{} An optional way (read "It works, but only sorta") would be to add code
{} to the /etc/cshrc and /etc/profile to log every time they are invoked.
{} /etc/cshrc is sourced every time a login csh is invoked.  Likewise,
{} /etc/profile is sourced every time a login sh is invoked.
Since this will only log SUCCESSFUL logins, you may also have a deeper
look into /etc/wtmp, which does the same - and quite correct.
(Even logs uucico's and otherm stuff, since it's written by getty, login and
 init !!!)

A way to also trace fail-logins could ONLY be achieved, by installing a new
login. 

In our company we use a login, which features:

	-	Logging of fail-logins
	-	Restriction of logins depending on the port being used
		and the time. (You may reserve ports for either a list
		of users and/or a list of groups ...)
	-	Limitation of online-time per day.
	-	.hushlogin (quick login without showing /etc/mot[dw] and
		other stuff (last login time etc.) - good for uucp logins)

... plus other fancy stuff :-)

We're currently thinking about selling it, since others do so (have a look
into the THIRD PARTIES PRODUCT DIRECTORY from SCO ...)

If we're NOT going to sell it, I'll post it ...

Clemens Schrimpe, netmbx GbR (Berlin, West-Germany)

UUCP:	csch@tmpmbx	{pyramid|unido}!tmpmbx!csch
BITNET:	csch@db0tui6.BITNET	csch@tub.BITNET
TELEX:	D+186672 net d
FAX:	49303614093
PHONE:	+49-30-332 40 15

davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/11/88)

Since you want good and bad logins, I think the easy way is to replace
the login program itself. Here's what I would do:

	rename login to something like real.login
	create a small C program
		open log file
		log date/time
		exec real.login

If you run accounting you can see just the failed attempts by looking
for jobs named login. When login works there's an exec and the process
name changes.

You can write your own login fairly easily, using the system call to
getpass, then convert it by (I can't remember) and check it.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

Dave_H_Close@cup.portal.com (05/13/88)

The following is a summary of replies received in response to my article.

===============================================================================
===============================================================================

Original article: <5153@cup.portal.com>

Under VMS, I am able to set an alarm which will log all login attempts
via a dial-in port.  (I can also set many other types of alarms.)  The
alarm does not depend upon the caller being successful at logging-in;
repeated bad attempts are also useful information.  I would like to
enable a similar facility for Xenix 386 2.2.  Does anyone know how this
can be done, or if it can be done?

===============================================================================

From: Harold_W_Hankins@cup.portal.com

i'd suggest you replace the /bin/login that comes with xenix with one of
the public domain ones.  since these come in source form, you shouldn't
have much trouble modifying them to log all login attempts either to a
file or to the console.   i think the machine "killer" in dallas has the
sources in their archives.  if you can't find one anywhere else, drop
me a line and i'll find it and mail it to you.
hank

===============================================================================

Sco Xenix does not support any type of login `log'.  The clean way
would be to hack /etc/login to log all login attemps.  This would take
time and money.

An optional way (read "It works, but only sorta") would be to add code
to the /etc/cshrc and /etc/profile to log every time they are invoked.
/etc/cshrc is `sourced' every time a login csh is invoked.  Likewise,
/etc/profile is sourced every time a login sh is invoked.

Sample code:

	who am i >> /etc/login.log

This code will work for /etc/profile and /etc/cshrc.

Disadvantages:

	o Not all login attemps are recorded.

	o Only csh and sh logins are record.  Users with
	  other login shells that do not source one of the above
	  files will not show up in the log.  vsh (the visual shell)
	  and uucp transfer logins (/usr/lib/uucico/uucico) will not
	  be logged.

Hope this helps.

pax, Keith
-- 
[  Keith   ]  UUCP: {ucsd, cbosgd!crash, sdcsvax!crash, nosc!crash}!portnoy!ag
[Gabryelski]  INET: ag@portnoy.cts.com              ARPA: portnoy!ag@ucsd.arpa

===============================================================================

Re ag@portnoy.UUCP (Keith Gabryelski) (preceding message):

Since this will only log SUCCESSFUL logins, you may also have a deeper
look into /etc/wtmp, which does the same - and quite correct.
(Even logs uucico's and otherm stuff, since it's written by getty, login and
 init !!!)

A way to also trace fail-logins could ONLY be achieved, by installing a new
login. 

In our company we use a login, which features:

	-	Logging of fail-logins
	-	Restriction of logins depending on the port being used
		and the time. (You may reserve ports for either a list
		of users and/or a list of groups ...)
	-	Limitation of online-time per day.
	-	.hushlogin (quick login without showing /etc/mot[dw] and
		other stuff (last login time etc.) - good for uucp logins)

... plus other fancy stuff :-)

We're currently thinking about selling it, since others do so (have a look
into the THIRD PARTIES PRODUCT DIRECTORY from SCO ...)

If we're NOT going to sell it, I'll post it ...

Clemens Schrimpe, netmbx GbR (Berlin, West-Germany)

UUCP:	csch@tmpmbx	{pyramid|unido}!tmpmbx!csch
BITNET:	csch@db0tui6.BITNET	csch@tub.BITNET
TELEX:	D+186672 net d
FAX:	49303614093
PHONE:	+49-30-332 40 15

===============================================================================

Xenix does have a user log, and logs all users. The log file is called
/etc/wtmp, and holds records of each login. It has the exact format of the
/etc/utmp file, and a program can be written using the data structures found
in #include <utmp.h>.

You can also display the wtmp file by using the who command:

who /etc/wtmp

which will read the wtmp file, and so you the login time and date for each
user.

If the file /etc/wtmp does not exists, then it will not keep a log. If you
don't have it, then you can just create one by cat /dev/null > /etc/wtmp.

On the flip side, the wtmp files can get enormous if you have a busy system.
If you don't need it, removing the file will stop the logging. 

Kevin

kevinr@june.cs.washington.edu

===============================================================================

Since you want good and bad logins, I think the easy way is to replace
the login program itself. Here's what I would do:

	rename login to something like real.login
	create a small C program
		open log file
		log date/time
		exec real.login

If you run accounting you can see just the failed attempts by looking
for jobs named login. When login works there's an exec and the process
name changes.

You can write your own login fairly easily, using the system call to
getpass, then convert it by (I can't remember) and check it.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

===============================================================================

From: sun!dasys1!mikej (Mike Johnston)

Dave,
    Yes it can be done but I believe you will have to modify the "getty" program

-- 
Michael R. Johnston                                              / cpmain!mrj
Franchise Data Specialist                      cmcl2!phri!dasys1! 
Career Employment Services Inc.                                  \ mikej

===============================================================================
===============================================================================

Thanks to all who replied.  I have the SCO 3rd-party directory (1st edition)
and have looked through it.  Maybe I missed something but I didn't see any
replacement login programs.  Perhaps Clemens Schrimpe meant some of the very
elaborate (and, probably, expensive) user shell systems described.  In any
case, my perusal of the directory indicates there might be a market for his
program, but I hope he chooses to distribute it free.  I have experimented
with the "who /etc/wtmp" approach and it does seem to offer most of what I
want.  All the records are there, though the extraction leaves something to be
desired ("who -aT /etc/wtmp" causes my screen to flicker, something I've never
seen before; other multi-screens are unaffected).  What I really want is a
"write"-type message to root (or maybe all screens) when a remote login attempt
occurs.  Soon I'll check into what killer may have available - they do stay 
pretty busy.

Dave Close, Compata, Arlington, Texas
email:  compata@cup.portal.com or sun!cup.portal.com!compata
telex:  6295-5830