Transparent TCP Tunneling

The transparent TCP tunneling feature captures the TCP traffic of hosts defined in the Tectia configuration and uses encrypted tunnels for sending the data. No changes are required to the configuration of the application software.

On Windows, transparent TCP tunneling captures also connections initiated by applications running at low integrity level on Windows Vista and newer platforms. This is mainly because Internet Explorer (version 7 and newer) runs at low integrity level when configured for protected mode, as by the default.

	Note
	Connection sharing between SSH applications of one user running at low integrity level and those running at higher integrity levels is disabled for security reasons.

For example, let us assume that the sshg3 client has opened and authenticated a secure shell connection using a profile named tunneling_profile (and sshg3 is running at normal integrity level). Then, Internet Explorer running in protected mode (and at low integrity level) establishes a TCP connection which is tunneled using the same profile tunneling_profile. Connection Broker behaves as follows in this situation:

A new SSH connection is opened and authenticated for the Internet Explorer process.
Previously, the existing connection would have been shared between the two applications, only opening new channels as needed.
However, connections are still shared among all processes that run at low integrity level. Similarly, connections are shared also among processes running at medium and higher integrity levels.

The transparent TCP tunneling is activated in the Connection Broker configuration, where you can also specify the applications to be tunneled and define filter rules that control the setting up of the tunnels in detail. Once activated, the transparent TCP tunneling feature automatically captures the defined applications and the Connection Broker creates Secure Shell tunnels to the defined servers, that can be Tectia Servers, Tectia Server for IBM z/OS, or any SSH2-capable Secure Shell servers.

For information on the configuration settings in the XML file, see the section called “The filter-engine Element”, and for settings in the GUI, see Defining Transparent Tunnels.

When a global configuration file exists, (for example when Tectia ConnectSecure is controlled by Tectia Manager,) and it includes the filter-engine element, those settings are applied. The global configuration file is located in /etc/ssh2/ssh-broker-config.xml on Unix, and "C:\Program Files\SSH Communications Security\SSH Tectia\SSH Tectia Broker\ssh-broker-config.xml" on Windows.

Principle of Transparent TCP Tunneling

The principle of transparent TCP tunneling is shown in Figure 6.2.

Figure 6.2. Transparent TCP tunneling

The following steps happen in transparent TCP tunneling:

A user or script on the local host starts an Application client that begins to establish a connection to the Application server.
The Tectia connection capture module captures the connection before it leaves the client side. Only user processes are captured, and processes running with the SYSTEM account are passed through.
The Tectia Connection Capture queries from the Connection Broker the filter rules that specify which connections to capture and what filter rules to apply to the connection; whether to block it, let it pass directly, or to tunnel it securely through a Secure Shell server.
The filter rules are defined in the Connection Broker configuration. Connections can be captured based on the application used and the destination address and/or port, or all application connections can be captured.
If the connection requires tunneling, the Connection Broker creates a TCP listener as a local tunnel end point and the application connection is redirected to that local end point.
Tectia Client can extract the user name, password, and destination host name from the secured application, and use them for authentication and connection setup with the Secure Shell server.
The Connection Broker module creates an authenticated and encrypted Secure Shell tunnel to a Secure Shell server, which, if necessary, relays the traffic to the destination host. The Secure Shell server can be the application server specified in the original connection request, or another server configured in the filter rules.
The Secure Shell tunnel is terminated at the Secure Shell server.
The Application server is the end point of the connections. If the Application server is located on a third host, the relayed connection from the Secure Shell server to the application server will be unsecured. This is why it is recommended that there is at least one Secure Shell server in each physically secured area, for instance, in a machine room.

Example on Tunneling Telnet Connections (Unix)

This example shows how transparent TCP tunneling can be used to secure Telnet connections between a corporate network and external servers over the Internet.

In the example use case, the users have Unix hosts with Telnet applications. Since Telnet includes no internal security measures, Tectia ConnectSecure is also installed on each host to provide security. The users make Telnet connections to port 23 (the dedicated Telnet port) to application servers outside the company. The destination hosts are required to have Secure Shell servers running on them, either Tectia Server or some other standard-compliant server.

Figure 6.3. Transparent TCP tunnel securing Telnet connections

The host keys of the destination hosts need to be saved as known host keys on the local hosts before using the transparent TCP tunnels. To fetch and save the host keys, connect once to each of the destination hosts using command sshg3 and choose save in the host key dialog.

Also, the user public keys need to be delivered to the Secure Shell servers. On Unix, the ssh-capture process cannot always extract the password prompt from the application, so the Secure Shell connections need to be established non-interactively. For this reason, the users should use, for example, public keys without passphrases.

The transparent TCP tunnels are defined in the Tectia ConnectSecure configuration to tunnel all traffic going to port 23. Tectia ConnectSecure can use the destination host name directly from the connection-originating application, so it is not necessary to create a separate connection profile for each destination host. The transparent TCP tunneling configuration is made in a single filter rule set in the Connection Broker configuration file ssh-broker-config.xml:

<filter-engine>
  . . .
  <rule host=".*"
        ports="23"
        action="TUNNEL"
        hostname-from-app="YES"
        fallback-to-plain="NO" />
</filter-engine>

For detailed description of the configuration elements, see the section called “The filter-engine Element”.

To activate the transparent TCP tunneling, restart the Connection Broker or make it re-read its configuration by using command:

$ ssh-broker-ctl reload

To start tunneling the Telnet connections made to port 23, run command:

$ ssh-capture telnet some-server.example.com

You can also start a bash shell session with connection capturing enabled for all commands. Run command:

$ ssh-capture bash

With the transparent TCP tunneling active, all Telnet connections from the Unix client hosts to the remote servers will be securely tunneled. The client host applications require no modifications, so the users can keep working with the existing tools as before.

Note that there are limitations on capturing suid applications. For more information, see the Note about capture restrictions.

Example on Tunneling E-mail Service (Windows)

This section gives an example of configuring encrypted tunnels for an e-mail service on Windows. Transparent TCP tunneling is used for establishing tunnels that can be utilized as a secure transport between an e-mail client and an e-mail server communicating over the Internet.

This scenario describes a typical configuration for remote users for accessing the company's internal e-mail services transparently. In the test scenario, access from the client's private network to the Internet traverses through a SOCKS4 server, and the client-side has Tectia ConnectSecure installed. Access to the company's internal network, including the e-mail services, goes via a gateway host which has Tectia Server running.

Figure 6.4. Transparent TCP tunneling securing e-mail connections

Before e-mail delivery, Tectia ConnectSecure automatically creates a transparent TCP tunnel between the client host and the Tectia Server gateway for SMTP/IMAP/POP protocols. The encrypted tunnel ends at the gateway, and from there onwards the e-mail traffic is transmitted unencrypted in the company's internal network.

To create the configuration using the Tectia Connections Configuration GUI, do the following:

On the Connection Profiles page, click Add profile to add a new connection profile for the gateway server host. Enter the profile name and click OK. In the example, the profile is named paper.
Select the created profile from the Connection Profiles list, and specify the connection details in the following view.
Figure 6.5. Configuring connection profiles
By default, the profile name is assumed to be the host name of the destination server, but here we link the profile name to a server called host1234. Click Apply when the settings are ready.
On the Transparent Tunnels → Connection Capture page, select the Enable transparent tunneling at startup check box.
Figure 6.6. Defining the connection capture settings
On the Transparent Tunnels → Filter Rules page, click Add to add the filter rules which define the applications and ports to be captured and tunneled. In this example, only TCP ports related to e-mail delivery (IMAP, POP, SMTP) are forwarded to the gateway server through profile paper.
Figure 6.7. Adding filter rules for email services
Under Action, it is possible to select how the destination host is defined; either the host defined in the connection profile is used, or the host definition is received from the application. Now that we have a gateway server in this example, we will use the hostname defined in the profile, and the Use host name from the application is left unselected. In case we had a Secure Shell server running on each destination server, we could use the host names from the application.
The created rules are listed in the Filter Rules view. You can return to editing a selected rule by clicking Edit, and you can arrange the order of the rules with the up and down arrows. Place the most specific rules first. In this example, the order is not significant.
Figure 6.8. Defining filter rules

Once transparent TCP tunneling has been activated, it captures the e-mail traffic to the hosts defined in the Tectia configuration and uses encrypted tunnels for sending the data. No changes are required to the configuration of the e-mail application.

When the tunnel is opened, the user is prompted to authenticate to the gateway server. Setting up public-key authentication to the server is recommended. For instructions, see Managing Keys and Certificates.