Interim SUMMARY: Logging the actual commands of a dial in session

From: Robert Honore (robert@digi-data.com)
Date: Thu Jun 26 2003 - 11:03:38 EDT


  Many thanks go to the following persons.

Iain Barker,
Alan Davis,
Selden E. Ball Jr.,
Jesper Frank Nemholt,
Mark Deiss

The suggestions ranged in several directions.

I can connect a jumper to the TX and RX lines of the console serial port
and pass the resulting signal through a buffer to feed that to the
station where I will do the logging.

While I can to that, and it was one of the methods I tried before, since
I do not have a buffer to amplify the signals I decided to avoid that
because the location already has a lot of electrical noise.

I did decide to try the other two suggestions, though. They both
involve using console logging software.

The first one was to try to use ConsoleWorks from TecSys Development.
It is capable of making a timestamped log of all transactions on the
consoles of the systems. You can find out more about it at
http://www.tditx.com.

I am still reading up about this product to figure out exactly what I
must do to get it to work for me and will post another summary about it.

The other alternative also uses software to log the transactions on the
console of my systems, but it uses software called ConServer. It is
also capable of making a timestamped log of transactions on th econsole,
but has the nice feature that it is opensource, so I definitely will be
trying that one too. I will post a summary on the results of that.

You can find out more about ConServer at http://www.conserver.com.

I also received the following suggestion that, though it seemed up to
the task, I cannot use, because I do not have CA Polycenter.

This solution uses a node called an "Access server" which connects to
the terminal server and can field connections from the modem (if the
modem is attached to the access server), or from any other node in the
network. The Access Server is running CA Polycenter and will provide
ingress to the terminal server which is directly connected to the
console ports of my systems.

I can run expect scripts on the access server to perform other
activities other than the logging on this access server. In fact this
solution looks very sophisticated. If anyone wants to find out more
about it, drop me an email and I will forward the original text that I
had received.

Yours sincerely,
Robert Honore.

Original Question:
> Dear Fellow Managers,
>
> I have a problem that perhaps you might have already solved and was
> wondering if you would be willing to advise me as to how I should
> proceed. Let me describe the scenario.
>
> We have two GS160s configured as a cluster with a terminal server
> connected to the console of each of the GS160 systems.
>
> The situation is as follows. We have technicians and consultants who
> occasionally need to dial into the consoles to carry out troubleshooting
> and repairs for us. However our site rules do not permit me to admit
> them without being able to log all of their activities in some kind of
> tamperproof way. In particular, I need to record the exact commands
> that they enter and, if possible, also record the exact responses they
> get from the machines. I need to make this happen even if they should
> shut down the node, or bring it down to single-user mode or disable
> auditing and syslogd.
>
> To do this, it seems that I would need to record their keystrokes and
> the characters the computers return in reply to their commands. Now the
> solution I was originally thinking of was to put the modem on a
> minimally configured Alpha and use that to field the dial-in session and
> then redirect it to the console ports of the GS160s while copying the
> keystrokes and storing it on the Alpha system. However, I am not sure
> how to "tap the line" and actually copy the typed characters as well as
> the response characters to a file while allowing those same characters
> to go on to the console ports of the GS160s. So if it can be done, how
> can I do it?
>
> Now my plan might not even be sound so feel free to suggest a better way
> to log the commands.



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:25 EDT