Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

SSH Tectia

Policy rules

The policy rules define the SSH Tectia Connector tunneling policies. Each tunneling policy rule contains an application definition, a set of tunneling parameters, and other settings.

Source

This field specifies the hosts on which this rule is to be installed. In other words, it specifies the source host for connections that this rule applies to.

The hosts can be selected using a host group (from any view). The rule applies to all hosts in the selected group and in any of its subgroups. An individual host can also be selected by clicking Select host. If you need to select multiple host groups, you must create a separate rule for each host group.

Only hosts that have SSH Tectia Connector installed will actually receive and honor the rule.

Destination

Specifies the destination host(s) for connections that this rule applies to. The rule only affects those hosts that are in the specified destination group (or any of its subgroups), or the exact same host (if a host is specified). If a pattern is specified, then the pattern is matched against the name that the application making the connection uses to connect to the server.

Together with Application, this field determines the communications affected by the rule.

Application

Specifies the application to tunnel. This rule only applies to those communications that are matched by the application specification. Applications can be specified based on port numbers or executable file names, or combinations of these. Applications are named entities, and here you select the name of the application to use. See Application definitions.

Provided you have sufficient access rights, if the application you need is not defined, you can use the Edit button to edit the list of applications and then return back to the tunneling rule.

Action to perform

Specifies the action to perform for all matching connections on the hosts that this rule applies to. The action can specify encryption (tunneling), direct connection (no encryption), or blocking (denying) the connection.

When using encryption, you must also select the encryption method and parameters to use.

Note that even though blocking is also available, the tunneling rules are not really intended for firewalling purposes, but for making it easy to add encryption and integrity protection to existing applications.

Tunneling parameters

Specifies the encryption method and parameters to use. The encryption is specified by selecting a named encryption type. See Tunneling Parameters .

Provided you have sufficient access rights, if the encryption methods or parameters you would like to use are not available, you can use the Edit button to edit the list of tunneling parameters, and then return to editing the tunneling rule.

Nested tunnel server

You can use this setting to specify that the tunneled connections specified by the rule are tunneled through the host indicated by this field. This is most useful in remote access configurations, where a user is connecting from the outside to an internal network and connections should be encrypted both in external and internal networks. In such a scenario, you would typically configure the rule to match internal hosts based on their hostname pattern, set the tunnel end point as destination host, and set nested tunnel as the firewall host. This way, the communication is encrypted end to end as the internal tunnel end point hosts whose names are not visible outside can be accessed.

Server-side username

Specifies the username of an existing server-side user account used for tunneling.

When tunneling from a client to a server, the client must be able to log in to an existing user account on the server. There are two alternatives: either use the same username on both the client machine and the server machine, or log in using a fixed, shared user account. In both cases, the user should be restricted to tunneling services only whenever possible.

By default, if the server-side username is not defined, the Windows login name is used also as the server-side login name, and users have to authenticate themselves to the server using the authentication method(s) configured in SSH Tectia Server, for example password, keyboard-interactive for SecurID, or public-key authentication for smart cards.

In case the tunneled applications provide sufficient user authentication, it is possible to configure SSH Tectia to use a shared user account, for example with a shared password, not requiring user interaction.

Note that if the Destination for the tunneling rule refers to multiple hosts, each of the hosts must have the same user account with the same shared password.

[Caution]Caution

It is very important that the shared user account is properly configured on the server, not only restricted in the SSH Tectia Server configuration but also on the operating system level. The user should be denied at least terminal access and the file system permissions should be restricted. It is recommended to deny also file transfer services and any other services for the user.

Unix server: To prevent shell access alltogether /bin/false can be set as the operating system login shell for the user. It is recommended to chroot the user in SSH Tectia Server, deny remote port forwarding, and allow only intended local port forwardings.

Please see SSH Tectia Server documentation for details on available restrictions.

Server-side user password

Specifies the shared password corresponding to the server-side user account used for tunneling.

[Caution]Caution

The shared password is stored as plaintext in the Connector configuration file as a default response to the user authentication dialog. A real user account should never be used as a shared user account. See Server-side user name for more details.

Tunnel end point

You can use this setting to specify that instead of being tunneled directly to the destination host, the matched connections are tunneled to the host indicated by this field. This is most useful in remote access configurations, where a user is connecting from the outside to an internal network, and internal hosts are not accessible from the outside (and often even their names are not visible to the outside). In such a scenario, you would typically configure the rule to match internal hosts based on their hostname pattern, and tunnel (from the outside) to the firewall. This way, communication is encrypted over the Internet, and the name of the internal host is evaluated at the firewall, so internal hosts whose names are not visible outside can also be accessed.

Another important use of this feature is for securing connections to mainframes or other machines whose resources are too expensive to use for encryption processing (or that are not natively supported by SSH Tectia). In this scenario, you would use another machine in the same machine room with the mainframe as a front-end for encryption processing. The connections would be tunneled to the front-end, and then go as plaintext within the machine room to the mainframe. The front-end could be either an existing machine used also for other purposes, or a dedicated front-end machine.

===AUTO_SCHEMA_MARKUP===