Learning about remote users

[John Chambers]

Suppose that you have a Unix system (BSD, Sys/V, Xenix, etc.) connected to
a network via the usual TCP-style networking, and you'd like to learn what
you can about who is logging in. The obvious thing to do is to insert some
things into the local .login (or .profile or .kshrc or /etc/profile or ...)
that invokes a little (?) program whose purpose is to create an audit trail
of remote logins.  Is it possible to learn anything interesting about the
remote user?

The first problem, of course, is identifying which logins are remote, and
where they come from.  You can usually determine the latter by looking at
the major/minor device numbers on the stdio files, and checking to see if
they are pseudo-terminals.  Will this work everywhere?  What systems, if
any, are exceptions.

As for identifying the originating system, I suspect that it is doable,
though I haven't yet determined how to do it.  The evidence I have that
it is doable is that who(1) does it on BSD systems.  Does anyone know
how it is done?

Beyond this, is there anything else that can be learned?  Is it possible
to find out the userid (numeric and/or symbolic) that originated the call?
Is there any way to query the originating system at all?  If so, what can
my program ask for?

Is there a way to determine the mechanism of the call (telnet, rlogin, or
possibly a sendmail debug session ;-)?

With all the growing concern about security aspects of networks, it'd be
quite useful to be able to collect such audit trails.  It's obvious that
a lot of useful information is available on the two ends of the session.
But it's not obvious that a user-mode program can get at it.  I'd like to
start writing a program that does whatever can be done to produce such an
audit trail.  Any ideas?

Needless to say, something that doesn't require kernel mods would be preferred,
though like most hackers, I wouldn't object to an excuse to muck about down
below a bit...

-- 
John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)

[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]