Today we are going to dive into how to setup and use Thinklogical’s line of Secure Console Servers. What I like about these devices (available in 8-, 16-, 32-, and 48- port models) is that they are actually running Linux, so the setup and configuration is a breeze via the command line for anyone comfortable on a Redhat based system.
Initial Device Setup and Configuration.
There are two pretty simple ways to connect to your SCS one you have unboxed it and have powered it up.
The first is via IP. The default ip address of the device is 10.9.8.7. So plug one end of an Ethernet cable into a network port on a laptop or desktop. Plug the other end of this same cable into the first network port on the SCS and configure your workstation so that it has an IP address on the same network as the SCS. In my case I set the IP address of my laptop to 10.9.8.8. No Netmask or Gateway needed when connected directly. This method enabled me to either ssh directly into the device or connect to it via web browser.
The second method is via a serial connection to the SCS’s console port. In this case I fired up minicom (hyperterm or putty will do as well if you are running Windows) and configured it to use /tty/USB0, which is the device number associated with my USB to serial converter. If you have an serial port on your laptop you can skip the USB to serial adapter and just plug right into the serial port on your workstation. This method allows you to login directly to the device’s console. In this scenario, I used a Cisco console cable to connect the two devices together.
The initial login and password are root/root. It goes without saying that you need to change this password ASAP.
Configuring your Serial Connection
The “pm” command can be used to test to see if you need your connection is correct as its possible that you may need to modify a ports settings to use DTE, instead of the standard DCE that you will see on most (if not all) Solaris Servers and network devices.
For example, I have just connected an ancient Sun Ultra 5 to TTY port 2 on my SCS. Using the command below I can verify that the initial connection is correct.
[root@scs01 ports]# pm /ttyB2
/dev//ttyB2 is correct (dce)
To scan and review all ports at once use the command below. Empty ports will display as shown.
/dev/ttyB4 is disconnected/off or the attached device does not support any hardware signaling
/dev/ttyB5 is disconnected/off or the attached device does not support any hardware signaling
/dev/ttyB6 is disconnected/off or the attached device does not support any hardware signaling
/dev/ttyB7 is disconnected/off or the attached device does not support any hardware signaling
To modify port parameters such as speed and duplex you can edit the following file, /etc/rc.d/rc.serial. Each tty device has its own line of config in this file. I sugguest making a backup of the file before you start hacking it apart.
Note that the default configuration for a port is shown below. This configuration works right out of the box for an older Solaris server with a standard RJ45 serial port.
- DCE / 9600, no parity, 8 data bits, 1 stop bit
If your server does not have an RJ45 serial port, but rather has a DB9 or DB25 serial port , you can use one of the adapters that ships with the device.
Specifically for a DB9 serial port, you use part number ADP-0000008-R (DB9F to RJ45F) and for a DB25 port use part number ADP-0000005-R (DB25F to RJ45F). Specific pin outs can be found in Appendix F in the PDF below.
To change the label or description on a port you use the stty command as shown below. In this example I am changing the “name” of port 2 to fatmin.
[root@scs01 ports]#stty –name=fatmin -F /lsi/ports/port2
Note that the default port name is going to be port<N>. You must know the current name of a port to change it. Check /lsi/ports for a list of all ports and their names (aliases).
The SCS has the ability to “listen” and “record” console messages that are sent via serial to the device. Each tty has a port buffer that can hold a maximum of 256k of data. The SCS can write console messages to this port buffer for the purpose of historical troubleshooting. Even if you were not on the console of a server to catch the error that was related to the 3am crash of your server, you can still check your port buffers to see if this information. Note that all port buffers are stored in memory, so they are lost when the SCS is rebooted.
You can view a port’s buffer with one of the with the less command or the cat command. So in this case my port is now called /lsi/ports/fatmin
So in this case – I run the command below
[root@sc01 ports]# cat buf_fatmin
Connecting to a Device Via the SCS Console Server
Ok so now lets connect to a device via the SCS. There are a few ways that you can do this. In this instance we are going to ssh directly to the tty of our choosing. Note that in this example our SCS has the IP address of 10.1.0.55 and we want to connect to the port with the label of “fatmin”
$ ssh email@example.com -t connect fatmin
We also have the option of connecting via ssh directly to the scs and the running the connect command to connect to the port
[root@scs01 log]# connect 2
Entering Interactive mode on port #2 (2)
Getting Familiar with the LSI Commands
As stated previously, your SCS is pretty much a Linux machine, and its very easy to configure because of this. I personally was able to apply many of my standard OS hardening settings to the SCS. That being said there are several commands available for use that are specific to the SCS. You can review these via running the man command as shown below. Note that LSI somehow stands for “Logical Solutions Secure Console Server”.
To view a list of user commands…
# man 1 lsi
To view a list of LSI created or managed files…
# man 5 lsi
To view a list of built in system command…
# man 8 lsi
Note that I am just getting started with this device, so expect this article to be updated from time to time. If I feel the need to create another article on the Thinklogical SCS I will link to it here as well.