Dedicated networking between partner companies is expensive; the Internet is handy and cheap. Yet security requirements are often high. Can you use the Internet and add extra security without great expense? SSH tunneling may do the job.
Like all other traffic in the digital universe, B2B transactions are increasing at an alarming rate. This is a win-win proposition; increased data-sharing generally increases both the strategic and tactical processes of any business alliance, which yields improved responsiveness and efficiency, and, consequently, stronger market performance. But this boon comes at a price, and more and more that price is the construction of many data pathways and system accommodations to keep information flowing from many points.
For many of these interfaces, you must carefully construct secure and permanent avenues for data exchange between your company and your partners—expensive but worth it. On the other hand, you may have found that, increasingly, such connections need to be made on the fly: cross-database access by remote users in the field, for instance; intercompany messaging/e-mail; and ftp/POP3 exchange of transactional data, for local processing purposes.
These kinds of transactions are not the sort that can justify a dedicated channel of information, and the dedicated channels are often not sufficiently flexible (or secure across the necessary conduits, such as the Internet) to accommodate them. New paths must be forged, therefore, to facilitate such ad hoc exchanges—and this raises new security issues. How do you cut a temporary tunnel through the Internet, or across some other insecure terrain, and keep it intruder-free?
SSH tunneling may be your answer. A secure alternative to Telnet, SSH—Secure Shell port forwarding—adds certificate-based security to remote command-line interface with a server. You can use it for a variety of remote functions that could benefit from enhanced security: e-mail access, ftp and POP functions, and SQL sessions, to name a few.
How SSH tunneling works
The idea behind SSH tunneling (or, more precisely, port forwarding) is to forward TCP traffic that is insecure through Secure Shell. In essence, an ad hoc encrypted point-to-point tunnel is created across Internet resources, permitting you to secure POP3, HTTP, SMTP and ftp connections, among others.
Access to corporate intranet Web pages may be secured in this manner, as well as remote SQL sessions.
What makes this particularly attractive as a feature of B2B relationships is that it calms the fears of senior management with regard to opening up private company resources to outsiders. Even if the outsiders belong to a partner company, executives get nervous about opening up database access beyond in-house boundaries, because of the security considerations. Increasingly, however, B2B means sharing information—so the added layer of security makes remote database access less worrisome.
Secure shell port forwarding requires only IP connections between remote client and server. Older VPN solutions, such as those using IPSec, aren't so simple, because Network Address Translation can be problematic between networks; special protocols are needed because NAT breaks IPSec connections.
What's going on here is that SSH connects TCP/IP ports on local and remote machines, specific to the protocol(s) being tunneled (which are port-specific). Think it through in reverse and it will be obvious: if SSH is monitoring a port, it can encrypt whatever it receives from the application connecting to that port (which specific protocols and applications must do on designated ports)—and decryption occurs on the other end in exactly the same way, because of the identity of the receiving port and the secure shell that's enabled for that port. Once the tunnel is established, client-server authentication can take place as it normally would.
The central consideration, protocol-wise, is the use of ports. If you know your ports, you can very easily enable SSH Tunneling for B2B operations. The reason this consideration is central is that, in each of the functional examples below, port assignment is paramount.
You can download SSH client software readily over the Internet from any number of sources. There are several versions of OpenSSH for Windows as well as alternatives to SSH; Mac users have their own SSH as well as variations like Nifty Telnet SSH. Of course, Linux users aren't excluded (see www.openssh.org/portable.html). If you don't like these choices, a Google search will turn up dozens of others.
Securing remote SQL sessions
Let's start with using SSH to secure remote SQL queries, because the concept of sharing databases across company boundaries is a bold but progressive idea, and we'd like to see it proliferate. Why would you not want to share mutually-beneficial tactical data? Security is the biggest reason not to, and that's where SSH can help you out.
Set-up. Installation of SSH means setting up an OpenSSH server (or the equivalent), instructions for which will depend upon which SSH you have downloaded, and the operating system being used on the server side. (If you're using Windows for your SQL server, you don't necessarily have to use a Windows version of SSH; it's possible to use Linux to set up an SSH proxy to the SQL server.) Configuration options will generally include setting up administration for the SSH server and creating user groups.
The client side. In Step 1, what you've done is set up a "tunnel host." You've made it possible, on the server side, for a remote client (from your partner company, or from one of your own field personnel) to establish an SSH tunnel with your SQL server through a designated SSH port that will partner with the client to implement certificate-based encryption (of everything passing between them, including passwords). You will also need for clients in your partner company to install an SSH client application, to create the other end of the tunnel (PuTTY, a popular SSH client, is available as freeware, under GPL license).
Opening and closing tunnels. You can open and close SSH tunnels manually from a command shell; you can open and close them from within a server-side program with API calls; and you can configure OpenSSH to start during server boot. See the documentation for the version you are using for specifics.
Tunnel geography. When creating an SSH tunnel for a remote client transaction, a destination host and port are specified. (This can be done manually or it can be automated—see PuTTY documentation, or the how-to of whatever SSH client software you are using, for specifics.) The whole point of SSH tunneling is the nifty trick of forwarding ports beyond the SSH server (and this is internally handy for setting up SSH tunneling on a server where SSH itself is not installed!). So a client using an SSH tunnel is connecting to the SSH host through the home network's firewall, and is then forwarded by the SSH host to the database server with which the client wants to establish a session. The transaction is secure from the SSH host back to the client, and is behind the firewall for the journey from SSH host to the SQL server.
Using ports for SQL sessions. The next critical feature of the tunnel is the port assignment. With many B2B interfaces (ftp, e-mail, etc.), the port assignments are static; with SQL sessioning, they aren't. In setting up the tunnel, what you need to do is have agreement on both ends as to which port is being used.
A remote client manually initiates an SSH session, using the following command-line syntax:
# ssh clientname@sourcename
This opens a session. You can expand the tunnel's traffic potential by using some options in the command:
# ssh –L 1433:sourcename:1433 clientname@sourcename
(Note that you can substitute another port on the client side, as a possible confound to intruders—the traffic will be correctly routed on the server side, because you have specified the SSH host port. Note also that for SQL sessions, you can use any port number from 1024 to 5000.)
Save the session for future use. Unless you get a kick out of command-line interfacing, you can save the session configuration on the client side for future use.
There's more to B2B
Mutual database querying isn't the only B2B function that sometimes need to be ad hoc. Cross-company e-mail access, secure file transfers, and access to one or more corporate intranets are also part of the picture.
Securing ftp interfaces
Uploading and downloading files is considerably simpler than conducting an SQL session. The same basic format (seen under "Securing remote SQL sessions") applies:
# ssh clientname@sourcename
And, as seen earlier, you can specify and even re-direct ports with the following format:
# ssh –L 21:sourcename:21 clientname@sourcename
However, if you use port forwarding in an ftp interface, you're only forwarding the initial command channel; the second data channel will not be tunneled. What can you do?
It turns out there's an extension of generic port forwarding that is ftp-specific: ftp forwarding, which monitors the forwarded control channel and will create port forwards for you, as needed, to handle the data channels. If the server in question has a large number of remote clients, this is something you'll want to implement.
You can apply ftp forwarding with either passive or active ftp. To initiate passive ftp forwarding, the client sends the PASV command to the ftp server. The server will dynamically open a listener port to establish a data channel, and give the client the IP address and port number of the listener. The client will respond by creating a local port forwarding to that new destination. The data channel is thus an automatically-generated, secure "side tunnel."
In ftp active mode, the process flip-flops: the client generates a data channel on a local port, putting the listener on the client side, and establishes the channel with the server by sending its IP address and port number. The SSH client then creates a remote port forwarding from the server's localhost address to the client IP/port.
Securing remote e-mail access
Securing e-mail is easier still. One important consideration is that e-mail has a number of possible protocols, so it's important to be certain you're using the correct one, especially if you're tapping a partner company's server. Here are the key players:
POP2 (109) – incoming mail (an older protocol)
- POP3 (110) – incoming mail
- IMAP3 (220) – incoming mail
- IMAP4 (143) – incoming mail
- SMTP (25) – outgoing mail
As long as I'm noting a transaction that uses differing ports for differing directions (i.e., POP3 incoming, SMTP outgoing), it's a good place to note the –L, -R options in the ssh command. –L specifies the command syntax listener_port:remote_host:remote_port, and –R reverses it.
And you can use multiple –L entries:
# ssh –L 110:mailhost:110 –L 25:mailhost:25 (and so on …)
Securing Web server / corporate intranet access
Another B2B interface of increasing importance is the corporate intranet, which may include the company intranets of multiple companies. Navigating an informal intranet securely with SSH can mean accessing Web servers that are Internet-accessible (usually on TCP port 80, or 443 for secure HTTP). Or it could mean accessing Web servers that can't be contacted via the Internet, which usually means logging on to a firewall box, and it's here that the server-side SSH would reside.
You're setting up port forwarding with a Web server in either case. What's happening is that the remote client is listening on a port for data bound for the Web server's HTTP port 80—and the session terminates at the firewall, where the client is sessioned (the corporate intranet is secure, of course, from the firewall to the Web server). The Web server sees the client as an internal address from the firewall.
You may wish to consider tunneling intranet Web pages in any case, if those pages are password-protected, in order to ensure the encryption of passwords sent by remote users.
Securing other protocols
From here the possibilities become somewhat exotic, but may stimulate your creativity in terms of how you and your partner companies can interface in order to share information and apply real-time interaction in shared business processes.
I'll leave it here, with a few of these on the table for your further consideration: terminal emulation (telnet), port 23; network time protocol (NTP), port 123; Internet Relay Chat (IRC), port 194; Windows SMB file sharing, port 139 (and NetBios, 137 and 138); directory pages, port 389; Netscape Calendar, port 5730…
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.