kdq@demott.COM (Kevin D. Quitt) (06/03/90)
Is there a way that I (as root) can "tap into" a user to monitor
terminal activity? I specifcally would like to do this for the modem line.
--
_
Kevin D. Quitt Manager, Software Development 34 12 N 118 27 W
DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266
VOICE (818) 988-4975 FAX (818) 997-1190
MODEM (818) 997-4496 Telebit PEP last demott!kdq kdq@demott.com
96.37% of the statistics used in arguments are made up.cpcahil@virtech.uucp (Conor P. Cahill) (06/03/90)
In article <270@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: > Is there a way that I (as root) can "tap into" a user to monitor >terminal activity? I specifcally would like to do this for the modem line. Not in software (unless you modify the software running on that port to dump the data to a log file that you tail). If what you want to do is to be able to abitrarily "tap" into a data line you must do it with hardware. This can be done in several ways including 1. a data line analyzer that captures all the data 2. a poor-mans data capture which uses a second serial port on your system and a special cable that wires TXD from the modem port to RXD on the second serial port. You can then tail this serial port whenever you want. Be sure that you do not have a getty running on the port and that if the second port requires DCD to be high you should loop DTR back to DCD. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
bill@twg.UUCP (Bill Irwin) (06/03/90)
In article <270@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: > > Is there a way that I (as root) can "tap into" a user to monitor >terminal activity? I specifcally would like to do this for the modem line. I have had some success using the "tee" process. In the user's .profile, when it got to the place where the local menu system was going to be brought up, I modified it to read: menu | tee > .../.monitor This basically pumps all screen I/O from that point on into the ".monitor" file. If you use append (">>"), each session will be appended to the end of the file. The tricky part is that all escape sequences sent to the terminal are captured in the file. If you do a "cat .monitor", you will see a very fast version of the user's session (fast because any time the user spent thinking or looking at the screen will not be reflected in your viewing session), as though you were looking over their shoulder. But you need to view with the same terminal type that the user used, so that your terminal responds properly to the escape sequences fed to it from .monitor. In my experience, as soon as the user entered an application that put the terminal into "raw" mode, output into .monitor was suspended until they exited the application and became "cooked" again. This was frustrating. Kind of like following a lady spy and watching her go into the ladies room. You have to hang around outside waiting for her to out. How knows what secrets she passed on while she was in there! Also, I found that vi sessions didn't behave properly for the user being monitored. You loose the advantage of secrecy if the user knows (or suspects) they are being observed. I would be very interested in reading some responses that would suggest a solution to the vi and raw mode problems. -- Bill Irwin - TWG The Westrheim Group - Vancouver, BC, Canada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!van-bc!twg!bill (604) 431-9600 (voice) | UNIX Systems Bill.Irwin@twg.bc.ca (604) 431-4629 (fax) | Integration
rg@psgdc (Dick Gill) (06/09/90)
In article <270@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: > > Is there a way that I (as root) can "tap into" a user to monitor >terminal activity? I specifcally would like to do this for the modem line. > > I don't know of any simple (or even not-so-simple) way to do this with software. I approached the same problem in a quick-and-dirty way by putting a spare terminal in the machine room, connecting a breakout box in the data line between the computer and modem and constructing a makeshift terminal cable that picks up the receive and signal ground lines from the breakout box and feeds them to the terminal. Not elegant, but it is quick, cheap and effective; you will see on the monitor everything going over the modem line. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dick Gill Professional Solutions Group (703)761-1163 ..uunet!psgdc!rg
omerzu@quando.UUCP (Thomas Omerzu) (06/09/90)
In article <270@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: > >Is there a way that I (as root) can "tap into" a user to monitor >terminal activity? I specifcally would like to do this for the modem line. > I'm using a modified version of the Berkley `script', which was recently posted on the net. That version was intended as a `tutor' support, and sends it output immediately to one ore more terminals. I did some further modifications, which allow to switch monitoring on and off. My approach: The login shell on the modem line is replaced by a modified version of `script', called `bbs0'. It allocates an pty, forks twice for copying in- and output from modem to pty and vice versa, creates a fifo and execs `bbs1' on the corresponding virtual tty. `bbs1' can be any program, e.g. a user menu or a simple shell. At first the copying is only done between pty and virtty. But when I send a SIGUSR1 to the copy processes, they start to duplicate everything they get to the fifo. A `cat < fifo' will show the session on your screen. When you stop the `cat', the copy processes will receive a SIGPIPE and they stop copying to the fifo. This seems to work quite well. The problems reported by bill@twg.UUCP (Bill Irwin) in <165@twg.UUCP> concerning his `tee' version and vi or raw mode seem to not occur. Naturally, the requirement for the same terminal type for monitoring and login session does also apply to this solution. Some problems seem to come up when you have want to use software handshake on the modem line, since `bbs0' requires to set the modem line in raw mode. I did not yet find an appropriate solution for this. -- Thomas Omerzu, omerzu@quando.quantum.de
david@cs.uow.edu.au (David E A Wilson) (06/09/90)
>In article <270@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: >> Is there a way that I (as root) can "tap into" a user to monitor >>terminal activity? I specifcally would like to do this for the modem line. Put your modems on an Annex terminal server and you can use the tap command to do exactly this. This however opens up another can of worms being discussed elsewhere under the subject "Dial-up access to the Internet". Other than this, a physical tap onto the RS-232 line from the modem is a simple method.
raymond@ele.tue.nl (Raymond Nijssen) (06/11/90)
In article <1990Jun3.011111.1589@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >In article <270@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: >> Is there a way that I (as root) can "tap into" a user to monitor >>terminal activity? I specifcally would like to do this for the modem line. > >Not in software (unless you modify the software running on that port to >dump the data to a log file that you tail). > >If what you want to do is to be able to abitrarily "tap" into a data line >you must do it with hardware. This can be done in several ways including > > >-- >Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., >uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 > Sterling, VA 22170 There is another way, in software, without the need to adapt the software running on the modemport, to monitor the terminal communication. This can be achieved by constantly examining the kernel memory in which the getty buffers are located. After some experiments, you can figure out where they are located. Then, you can run a program acting as a spy. These programs are used by crackers, and it's quite easy for them, since /dev/kmem is world readable on most unix systems, for this is necessary for commands like ps, which examines lots of kernels buffers also. However, you need a lot of performance to avoid missing parts of the communication via this line, so in practice, this method can only be used on fast computers that are not heavily loaded, and it costs a great deal of CPU time, so i doubt whether it can be of use for monitoring an outgoing line. Nevertheless, it should still be considered as a security hole, and I wonder if it has been fixed in rel. 4. -- Raymond Nijssen raymond@ele.tue.nl
kdq@demott.COM (Kevin D. Quitt) (06/12/90)
I originally asked this question because of a user who calls in,
then goes out to dinner, or something. I just wanted to be able to
detect whether, in fact, there was *any* activity on the line.
After R'ing TFM, I found register S41 on the trailblazer plus, which
allows setting an inactivity timer by tenths of hours. This is exactly
what I needed. Thanks to those who replied, and/or posted.
--
_
Kevin D. Quitt Manager, Software Development 34 12 N 118 27 W
DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266
VOICE (818) 988-4975 FAX (818) 997-1190
MODEM (818) 997-4496 Telebit PEP last demott!kdq kdq@demott.com
96.37% of the statistics used in arguments are made up.cpcahil@virtech.uucp (Conor P. Cahill) (06/12/90)
In article <509@al.ele.tue.nl> raymond@ele.tue.nl (Raymond Nijssen) writes: > > [ discussion of reading clists from /dev/kmem deleted ] > >These programs >are used by crackers, and it's quite easy for them, since /dev/kmem is >world readable on most unix systems, for this is necessary for commands >like ps, which examines lots of kernels buffers also. > >CPU time, so i doubt whether it can be of use for monitoring an outgoing line. >Nevertheless, it should still be considered as a security hole, and I >wonder if it has been fixed in rel. 4. It is not a bug in most versions of unix. The programs that need to access /dev/kmem are usually set up to run as set-gid to the same group as the /dev/kmem entry, thereby only requiring group read access on the device, not general read access. PS-> ps doesn't read many kernel "buffers". It reads the process table and, if necessary, the u structure for each process. The rest of the information it uses comes from disk files (either /etc/passwd & associated files or the quick condensed version in /etc/ps_data). It may have to read some of the paging/swaping stuff to get the user structure info for swapped out processes. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
peter@ficc.ferranti.com (Peter da Silva) (06/12/90)
In article <509@al.ele.tue.nl> raymond@ele.tue.nl (Raymond Nijssen) writes: > Then, you can run a program acting as a spy. These programs > are used by crackers, and it's quite easy for them, since /dev/kmem is > world readable on most unix systems, I hope not. It's never been on any system I've used. > for this is necessary for commands > like ps, which examines lots of kernels buffers also. cr--r----- 1 sys sys 2, 1 Feb 6 1989 /dev/kmem -r-xr-sr-x 1 root sys 21494 Feb 6 1989 /bin/ps > Nevertheless, it should still be considered as a security hole, and I > wonder if it has been fixed in rel. 4. It's been fixed in Rel 3, Rel 2, Rel 0, System III, and V7. I'd check on our Suns, too, but they seem to be making trouble for TCP/IP. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.ferranti.com> 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com> @FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.