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.

An example

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…