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.

Continue reading →

This is a neat and very useful trick that I learned today. Lets say that you want to be able to monitor and log all keystrokes that are typed as root. This is particularly useful as normally you can only log when a user uses sudo to run a command. If the user has the abilty to become root however, then they have effectively eluded yourattempts to track their activity. Like Thomas Magnum shaking a tail, they are free to scoot around your island with the top down.

So how do you stop this from occuring? How to you log all activity and keystrokes made by root without implementing a bloated 3rd party software that will probably cost and arm and a leg? You use PAM you dingbat.

The secret sauce in this security burrito is the pam_tty_audit.so module. Here is how to use it,

Below is my stock /etc/pam.d/system-auth file

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Now look above and then look below at my modified system-auth file. Note the additonal session entry for pam_tty_audit.so.

[root@ip-172-31-21-28 pam.d]# cat system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_tty_audit.so enable=root
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Note that you will need to add the pam_tty_audit.so call to your /etc/pam.d/password-auth as well to ensure that you capture all of root's keystrokes, no matter how they log in.