Your browser does not allow storing cookies. We recommend enabling them.

SSH Tectia

Transparent TCP tunneling

SSH Tectia Client and SSH Tectia ConnectSecure can be used for transparent tunneling of TCP connections. Both SSH Tectia products can capture all network communication originating from client-server applications on the local workstation such as email clients, web browsers, and other software; and tunnel the connections to any Secure Shell server.

Transparent TCP tunneling feature can be used, for example, to enable company employees access their e-mail, the company intranet pages and shared files securely even when working outside the office.

SSH Tectia Client and ConnectSecure enable transparent TCP tunneling without the need to modify the tunneled applications. Hence, the main barrier for wider adoption of Secure Shell tunneling is eliminated, as there is no more need to reconfigure the local host addresses in the application client's network settings.

SSH Tectia Client and SSH Tectia ConnectSecure can secure network client applications that initiate connections to server applications using TCP communications. Other network protocols such as UDP are not supported. Note that applications that initiate connections from the server to the client are not supported.

Broad application support

Transparent TCP tunneling can be used to encrypt any TCP-based user client/server application including both commercial application software and internal legacy applications.

Authentication by applications

The client-server applications carry out their own authentication procedures, if any, the same way they would without the encrypted tunnel.

No application modifications needed

Transparent TCP tunneling requires no re-configuring of the application software or port settings. The Connection Broker configuration contains all necessary settings.

Easy configuration

The applications to be tunneled and the other tunneling settings are defined in the Connection Broker configuration with filter rules. The configuration can be made so that the SSH Tectia product uses the user name and the destination host definition from the tunneled application, so that it is not necessary to create a separate rule for each destination server. Both SSH Tectia Client and ConnectSecure can use the same configuration format.

Fine-grained policy control

Administrators can freely define application security policies including rules to tunnel, allow plaintext, or block specific client-side application connections. The flexible configuration interface provides administrators with multiple ways of specifying the tunneled applications; applications can be identified according to destination address and/or port, application name, or location of the application client binary.

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

Transparent TCP tunneling

Figure 3.4. Transparent TCP tunneling

The following steps happen in transparent TCP tunneling:

  1. A user or script on the local host starts an Application client that begins to establish a connection to the Application server.

  2. The SSH 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.

  3. The SSH 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.

  4. SSH Tectia Client or ConnectSecure 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.

  5. The secure tunnel is terminated at the Secure Shell server.

  6. 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.




What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now