SSH.COM is one of the most trusted brands in cyber security. We help enterprises and agencies solve the security challenges of digital transformation with innovative access management solutions.
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.
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.
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.
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.
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.
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.
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.
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.
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
Please see SSH Tectia Server documentation for details on available restrictions.
Specifies the shared password corresponding to the server-side user account used for tunneling.
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.
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.