The Connector engine itself is configured by the General Settings view of the Administration dialog (Figure 16-9), which applies to all outgoing connections.

Figure 16-9. Configuring the Connector engine

Sometimes it is necessary or convenient to bypass Connector and allow applications to initiate their own connections directly: this is known as pass-through mode. An option is provided to allow pass-through if the engine is disabled or shut down. If this pass-through option is disabled, then connections will be blocked, which might be appropriate if security policies mandate that only secure connections are allowed. A comma-separated list of applications can also be exempted from interference by Connector. Typically these applications are for network diagnostics (e.g., nslookup or ping) or related to direct use of SSH (e.g., the Tectia client, Accession Lite, etc.).

Applications frequently need to connect to secure servers within internal networks from outside of firewalls. External hostname lookups are commonly prevented, to avoid leaking information about the internal network, and because direct access to the secure servers is blocked by the firewall anyway. In such cases, Connector can be configured to return dynamically assigned pseudo (or fake) IP addresses to applications in response to hostname lookups. When the connection is forwarded across the firewall via SSH, the hostname lookup is done internally. This is similar to the naming support provided by SOCKS5.

A base address must be identified for the pseudo IP addresses. This should be chosen carefully to avoid conflicts with real addresses of machines that applications might need to contact. It is natural to use reserved addresses (e.g., the 10.0.0.0/8 network) for this purpose, but if applications detect the use of such reserved addresses and misbehave, then it may be necessary to use a suitable range of otherwise unused real addresses.

As we have seen, Connector works by modifying the Windows TCP/IP protocol stack. Other, unrelated packages that also modify the protocol stack (such as firewalls and VPN software) can interfere with the operation of Connector, and require that Connector’s protocol stack modifications be reinstalled, which in turn requires a reboot. An option is provided to automate this; no user confirmation is needed.

Connector’s SSH implementation supports FIPS mode, which can be selected by an option. [5.3.5]

In most cases, Connector operates silently, and behind the scenes. However, SSH servers can be configured to send banner messages to clients, and Connector has an option for displaying them. [5.6.1] In addition, Connector can display a splash screen as a brief security notification when new forwarded connections are created for applications.

The tray icon menu can be configured to control access to functions that affect the engine, to prevent unprivileged users from circumventing security policies. Of course, the Connector configuration file should only be writable by privileged users.

Settings for each server used for an outgoing SSH connection must be defined by the Servers view of the Administration dialog in Figure 16-10.

A display name is assigned to the collection of settings for the server. Connections to a server can be routed via a previously defined server, to set up chains of port forwardings, if required for nested firewalls.

Figure 16-10. Defining settings for outgoing SSH connections

The most important characteristics of the SSH connection can be specified for the server. The special token %USERNAME% means that the local Windows username is used for the remote username as well.

By default, Connector initiates SSH connections only when required to forward connections from applications, but an option is provided to initiate the connection when the Connector engine starts. Idle SSH connections are terminated by Connector after a specified timeout interval elapses.^[176] Normally, SSH connections are retained (even when idle) if any forwarding channels are still active, but Connector can be configured to ignore active channels when it closes idle connections.

The allowed authentication methods are specified as a comma-separated list, chosen from the set: gssapi-with-mic, publickey, keyboard-interactive, and password. Public-key authentication is especially convenient with Accession Lite acting as an authentication agent. [16.4] Accession Lite is included with the Tectia Connector package, and the agent can be started using the Connector tray icon menu. A predefined response can be stored in the Connector configuration for password authentication. This is insecure, since the password saved in the configuration file is not encrypted in any way, and the predefined response is intended only for situations when the application handles its own authentication using some other secure mechanism.

A proxy server URL can be specified using the same syntax as for the Tectia client’s SocksServer keyword or the SSH_SOCKS_SERVER environment variable. [7.4.7.2] HTTP forwarding is also supported, using a similar syntax. SOCKS4 is used by default, but an option is provided to use SOCKS5 instead.

A filename should be chosen to store the host key for the server. The key can be fetched automatically by the Connector administration program, but the fingerprint should be verified using ssh-keygen -F. [6.2.2] Host keys are commonly stored in the All Users profile folder.

The Connector engine consults a list of filter rules to decide how to forward outgoing connections by applications. These are configured by the Filters view of the Administration dialog in Figure 16-11.

Figure 16-11. Filter rules for forwarding outgoing connections

A display name is assigned to each filter rule. The filter rules are matched according to the DNS hostname or IP address requested by an application, and the first matching filter rule is used for the connection. DNS hostnames and IP addresses can be specified either literally or as patterns using the egrep regular expression syntax. DNS hostnames are case-insensitive.

In the usual case when an application connects using a DNS hostname, Connector scans the filter rule list. If a hostname match is found, then the first matching filter rule is used. The IP address returned to the application is taken from the filter rule if one is specified, or is otherwise dynamically assigned from the pool of pseudo IP addresses.^[177] If no matching filter rule is found, then the connection is initiated directly, with no port forwarding.

When an application connects using an IP address, Connector similarly scans the filter rule list, looking for a filter rule with a matching address, and uses the first filter rule that is found. Otherwise, if there is no matching filter rule, then Connector does a reverse hostname lookup using the IP address. If this lookup succeeds, then Connector performs a DNS hostname match, as described previously. Otherwise, if the reverse hostname lookup failed, then Connector blocks the connection. Any hostname specified for the filter rule is passed to the other side of the forwarded connection so that the server can perform the hostname lookup for the real IP address on an internal network.

Connections are forwarded based on the target port requested by the application, according to a list of connection rules for each filter rule. Each connection rule consists of a comma-separated list of ports, or the special value All, plus one of the following actions:

The first matching connection rule for the requested port is used. If no connection rule matches, then a direct connection is initiated.

Connections are also forwarded according to the full pathname for the application. The Connector administrative interface allows the specification of only a single application. This restriction was imposed as of Version 4.2, and is actually a reduction in functionality. Earlier versions of SSHConnectorAdmin allowed the specification of an application for each filter rule.^[178]

The Connector engine uses the configuration file sshcorpoeng.cfg in the installation folder. The Connector administration program saves its settings in the configuration file automatically, and is the usual way to change the configuration.

However, the configuration file uses a straightforward format and is easy to edit directly. Settings are grouped in hierarchical sections that are delimited by curly braces. Each setting is a keyword and value, separated by an equals sign, with one pair per line. Values are Boolean (FALSE or TRUE), decimal numbers, or quoted strings, which use C-language conventions for backslash escape sequences. This convention is unfortunate, because all backslashes for Windows filename separators must be doubled.

Some features can only be used by editing the configuration file, and are not available via the GUI-based administrative interface. For example, the filter rules shown in Figure 16-11 correspond to the configure file section:

    Filters = {
      secure_mail = {
        DNSNameRegexp = ".*\\.mail\\.example\\.com$"
        Application = "C:\\\\Program Files\\\\WhizBangMail\\\\MailClient\\.exe"
        RealIP = FALSE
        Connections = {
          connection1 = {
            Via = "mail"
            Port = "25,143"
          }
          connection2 = {
            Via = "DIRECT"
            Port = "0-65536"
          }
        }
      }
    }

Regular expressions or literal values can be selected independently for DNS hostnames and IP addresses by using any combination of the following keywords:

The RealIP keyword controls assignment of pseudo IP addresses for each rule.

A separate application can be specified for each filter rule. The application pathname is actually a pattern, using the egrep regular expression syntax. The combination of C-language conventions for strings and regular expressions leads to an abundance of backslashes. For the setting:

    Application = "C:\\\\Program Files\\\\WhizBangMail\\\\MailClient\\.exe"

the C-language string corresponds (collapsing the doubled backslashes) to the regular expression:

    C:\\Program Files\\WhizBangMail\\MailClient\.exe

which matches the pathname:

    C:\Program Files\WhizBangMail\MailClient.exe