Encrypting Informix Database Connections with Secure Shell (GE Security's Picture Perfect Enterprise Edition)

Updated 4/8/2004

Background

Database information exchanged between servers running Informix I-Star or IDS is sent in plain text. Anyone with root access to any gateway or firewall in the middle of the conversation can type tcpdump port 1960 -s 2048 -X and capture the entire conversation between two Informix servers as shown here:

I recently worked on a project where the customer needed to consolidate their four Picture Perfect 1.5.5 subhosts databases from an Enterprise system to a Picture Perfect 2.0 redundant system. I planned to access the customer's WAN via VPN and to use the MicroScope's Micro Copy tool to "push" the micros from each subhost to a fith server that would be attached to their network. Once that temporary server had received all of the micros from all of the subhosts, we would use the standard GE Interlogix PP 1.5.5->2.0 upgrade script to upgrade the database and migrate it to a new Dell PowerEdge 2600.

The fifth server was a 1996 vintage Intel machine with a 2GB Quantum Fireball SCSI drive and had served with distinction for several years before being replaced with a Dell PowerEdge. In anticipation of this upgrade, the customer had previously shipped it to our office.

Once we decided to use the Micro Copy tool however, we discussed the possibility of shipping the unit back to the customer and attaching it to their network in a central location where it could be "filled" with database records extracted other machines in the enterprise. The customer's IT department balked at this idea, having concerns about the diversion of critical IT resources during their all-important tax processing season.

Our second choice was to run the extra server outside of the corporate WAN and push data to it from each Picture Perfect host. This posed a problem because the data exchanged between the Informix servers would have been exposed as plain text over the Internet. Since Picture Perfect doesn't provide a means to encrypt the database traffic, we looked for ways to do it using freely available software.

The solution chosen to implement involved pointing a SSH client back to a SSH server at the colocation facility and using SSH's port forwarding feature to tunnel Informix's I-Star protocol inside of the SSH session. When we invoke the SSH client, we can specify that data which gets sent to the client machine's localhost (127.0.0.1) interface should be forwarded through the SSH tunnel and handled by a server at the other endpoint of the SSH connection.

One option is to the let the remote SSH server handle the database request itself. Another option was to specify that the remote SSH server pass the database request to a local machine which handles the request. I chose the latter, preferring to hide the Picture Perfect server behind the SSH server.

With this setup, we were able to consolidate 4 subhosts into a standalone host in 1.5 days. Here is how to duplicate it.

SSH Client End

Most SSH clients, including the non-graphical command line version that ships with Linux, support the ability to establish one or more protocol sessions with services running on the remote server. The client can also specify that the remote SSH server relays traffic to a third machine at the server end. This is easily done on the command line with a command such as:

Edit /etc/hosts, adding the externally visible IP address of your SSH server:

Edit /etc/services, adding the following line. Informix looks at this entry to determine which port to communicate with other databases.

Edit /cas/db/sqlhosts, adding the following line:

SSH Server The SSH server was a Dell C800 portable computer running Red Hat Linux 7.3 which was assigned an externally visible IP address. All services except Secure Shell (/usr/local/sbin/sshd) were disabled. Our colocation ISP punched a single hole in their firewall at port 22. The only way in or out of the box would be through port 22. You can also use NAT to further hide your boxes behind an inexpensive DSL/Cable router. I found that a full-blown firewall and DSL/Cable routers work equally well. Your server's /etc/hosts file should be edited to include the local IP address of the target server:

SSH Server Setup When a new server session is established, it starts up TCP sessions with any remote server and port specified by the client. Usually, these additional server sessions communicate with one of the well-known ports of the server. In our case, we want the SSH server to forward traffic from local port 11960 to remote port 1960 on a Picture Perfect server that has a local IP address behind the firewall.

As shown above, add new_pphost to the /etc/hosts file on your SSH server: 192.168.3.26 new_ppohst #target Picture Perfect host Add a user to your SSH server using any one of the many methods (adduser, useradd, linuxconf, etc...). For simplicity, this user name should match a user on the client machine. In our example, we will use install. This user will be required to authenticate with the server when the SSH tunnel is initialized.

Remote (Target) Picture Perfect Server Endpoint The target server needs to be configured to "trust" incoming database requests. Although those requests originate on a machine on the customer's WAN, they appear to have originated from the SSH server. Therefore, access must be granted as though users on the WAN exist on the SSH server. The easiest way to to do this is to add an entry to the /etc/hosts.equiv file for PP 1.7 and 2.0 or /etc/hosti.equiv file for PP 1.5:

Caution! This isn't recommended for very many circumstances since it essentially means that any one on any machine can do anything on this machine. Use it only in situations where all access to the machine is restricted such as the specific case we are describing here.

Back to the Client Machine Now, log into the client machine and create a shell script containing the ssh client command we showed above. For simplicity's sake, call it tunnel:

Save the shell script and execute it:

The system will return something similar to:

Supply the password you created on the SSH server. You will not obtain a shell. Instead, the cursor will drop to the next line and the process will remain that way until you terminate the session with a "."

You are now ready to try a database call. Remember, all database table names must be fully qualified with the database name (proteus), followed by the host name (localhost) and the table name. From a new window on the client, type:

The output should look exactly as if you were logged into new_pphost. For more information about Secure Shell, visit OpenSSH.