jc@minya.UUCP (John Chambers) (03/16/89)
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.]envbvs@epb6.lbl.gov (Brian V. Smith) (03/17/89)
In article <199@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >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? Yes, the program 'who' shows both the tty (pseudo-tty for remote login) and the originating machine in parentheses. This holds true for 4.2BSD, Ultrix and SunOs systems. I don't know about any others Brian V. Smith Lawrence Berkeley Laboratory, Berkeley -------------------------------------- We don't need no stinking signatures! We don't need no stinking signatures!
ellard@bbn.com (Dan Ellard) (03/17/89)
In article <2124@helios.ee.lbl.gov> envbvs@epb6 (Brian V. Smith) writes: > > In article <199@minya.UUCP> jc@minya.UUCP (John Chambers) writes: > >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 > >Yes, the program 'who' shows both the tty (pseudo-tty for remote login) >and the originating machine in parentheses. This holds true for 4.2BSD, >Ultrix and SunOs systems. I don't know about any others Unfortunately, the who program gets its information about the name of the user logged in on each line from utmp, which (at least on ULTRIX and SunOS 3.x) is publicly writable, so a clever user can dup the who, w, finger, and users programs. /usr/adm/wtmp is usually more secure, since it is only written to by login and init (run as daemons) and is not publicly writeable. I don't know if wtmp exists on SysV or Xenix, but I would be surprised if something equivalent doesn't exist. Your best bet is probably to write a new login program which kept track of whatever info you wanted about each login, if you are really serious about it. Other things to look at: ps, which gives info about who is logged in (reliably, as far as I know) and netstat, which tells which hosts have network connections to your host (even though it doesn't say who is logged in on them). Good Luck! -Dan Dan Ellard ellard@bbn.com
stefan@yendor.phx.mcd.mot.com (Stefan Loesch) (03/17/89)
I once did something to learn about possible "hackerattacks" on a SYS V Rel2 (later Rel 3) machine. You can only do it that way if you have src. SYS V lets you specifie ports which are "remote", and subsequently asks users who try to login on such ports for an additional dialup password you specified. We had several remote ports, modem and X.25. What I did, was modifying login.c, so that whenever the code for the dialup password was executed, login would write the following data to a certain logfile: username password dialuppassword time It also would say, wether the try was "successful" or not. I never found any breakin attempts, but as a side effect I could easily tell why a remote uucp call failed (we had transatlantic connection, so the lines were very bad mostly). regards stefan
scs@adam.pika.mit.edu (Steve Summit) (03/18/89)
In article <10561@yendor.phx.mcd.mot.com> stefan@yendor.UUCP (Stefan Loesch) writes: >What I did, was modifying login.c, so that whenever the code for the >dialup password was executed, login would write the following data to a >certain logfile: > username password dialuppassword time Why, pray tell, did you record the password(s) in the log file? How careful were you to protect the file against inadvertent read access? How carefully did you protect every backup tape made of the filesystem on which it resided? How did you inspect the file yourself without learning people's passwords? (I don't know about you, but I do *not* *want* to know people's passwords. For instance, whenever I write a password-cracking program to check for insecure passwords, I make its output file mode 000, and do chmod 400 file;wc file;chmod 000 file if I want to know how many it found.) This issue is discussed here from time to time, and the consensus is generally that recording unencrypted passwords, including mistyped ones, is a bad idea. Steve Summit scs@adam.pika.mit.edu
stefan@yendor.phx.mcd.mot.com (Stefan Loesch) (03/21/89)
In article <9925@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: > >Why, pray tell, did you record the password(s) in the log file? I wanted to see ESPECIALLY the passwords, to be able to tell when some- body tried to break in, wether he did it with inside information, or with password scanning. >How careful were you to protect the file against inadvertent read >access? How carefully did you protect every backup tape made of >the filesystem on which it resided? The file was mode 0 or 600 (can't remember) with owner root. So was the directory it resided in. Of that filesystem there never were any backups. >How did you inspect the file >yourself without learning people's passwords? (I don't know >about you, but I do *not* *want* to know people's passwords. For >...... >This issue is discussed here from time to time, and the consensus >is generally that recording unencrypted passwords, including >mistyped ones, is a bad idea. I generally agree. However, on this system everybody knew and agreed to the procedure (only ~ 20 people). To keep private stuff nearly everybody had his own machine, for which he alone knew the passwords. What good are passwords doing you, if you're root anyhow ? Unless people use their passwords on more than one machine, which is bad anyway. Stefan Loesch stefan@mcdphx!motpdq