TRESK White Paper¶

Glossary¶

Intranet¶

Your company’s local area network which is not directly accessible from the Internet.

Target¶

Computer or service inside Intranet which is not directly accessible from the Internet.

TRESK¶

T unnel Res olver C omponent - is part of Excalibur, consisting of several components. In the Excalibur context TRESK allows access to any Target inside the Intranet with almost zero infrastructure or policy (re)configuration.

TRESK-Server¶

TRESK-Server is a component of TRESK. TRESK-Server provides an endpoint which serves TRESK-V3-VM or TRESK-Client SSH tunnel initialization and handles actions needed for successful SSH tunnel establishment, such as creating temporary users with appropriate public/private key pair authentication etc.

TRESK-V3-VM¶

TRESK-V3-VM is a component of TRESK realized as a Docker container with no further dependencies needed from OS. TRESK-V3-VM initializes SSH tunnel to TRESK-Server. After successful SSH tunnel initialization Target’s services are available from TRESK-Server through TRESK-V3-VM via specific ports.

TRESK-Client¶

TRESK-Client is a component of TRESK realized as a script (Bash on Linux or PowerShell on Windows) installed directly on Target, with no further dependencies needed from OS. TRESK-Client initializes SSH tunnel to TRESK-Server. After successful SSH tunnel initialization Target’s services are available from TRESK-Server through TRESK-Client via specific ports.

TRESK Overview¶

TRESK is responsible for establishing and managing connections between Target and TRESK-Server, either via TRESK-V3-VM or TRESK-Client.

TRESK-V3-VM and TRESK-Client serve conceptually the same purpose - SSH tunnel initialization and management between TRESK-V3-VM andTRESK-Server or between TRESK-Client and TRESK-Server. The difference in deployment between TRESK-V3-VM and TRESK-Client is that TRESK-V3-VM is installed inside Intranet as a single service, whereas TRESK-Client isinstalled on each Target separately.

After registration and SSH tunnel establishment all traffic between TRESK-Server and TRESK-V3-VM, or between TRESK-Server and TRESK-Client occurs inside this SSH tunnel (aka port forwarding via SSH or SSH tunneling) which is encrypted and thus safe even for transmitting information that uses an unencrypted protocol.

Communication between TRESK-V3-VM and Target is done using application protocol (SSH, RDP or VNC).

TRESK-Server¶

TRESK-Server is a component of TRESK. TRESK-Server provides an endpoint which serves TRESK-V3-VM or TRESK-Client SSH tunnel initialization and handles actions needed for successful SSH tunnel establishment, such as creating temporary users with appropriate public/private key pair authentication etc.

Deployment considerations¶

System: Any OS capable of running Docker

Location: Cloud

Exposed ports:

• 443 - Port used for /registration endpoint reachable via HTTPS protocol. This endpoint is used in case of TRESK-Client.
• 2222 - Exposed port of Docker container mapped to internal port 22. Used for establishing SSH tunnels to SSH daemon running inside Docker container.

TRESK-V3-VM¶

This chapter describes the establishing secure connection between Target  and TRESK-Server via TRESK-V3-VM. TRESK-V3-VM does not use SSH tunnel parametrer registration as it is in TRESK-Client case. TRESK-V3-VM uses two type of SSH tunnels, which are described later on this chapter:

1. Outer SSH tunnel
2. Inner SSH tunnel(s)

Fig. 1. TRESK-V3-VM - Example of established SSH tunnel

Basic principle of TRESK-V3-VM as shown on Figure is following:

1. TRESK-V3-VM - Establishing persistent Outer SSH Tunnel
2. TRESK-SERVER - Establishing Inner SSH Tunnel(s) on demand
3. Access Target from PAM Dashboard

Outer SSH tunnel¶

Outer SSH tunnel is initiated by TRESK-V3-VM. Outer SSH tunnel is persistent, which means that if this tunnel is closed e.g. due to network issues it is automatically re-established when network is available again. Command used for this establishment is following:

ssh -R \${REMOTE_PORT}:127.0.0.1:22 \ ${TRESK_SERVER_USER}@\${TRESK_SERVER_IP} -p \${TRESK_SERVER_PORT}

Inner SSH tunnel(s)¶

Established outer SSH tunnel allows accessing TRESK-V3-VM’s SSHD from TRESK-Server (other way as in Outer SSH tunnel establishment). This allows the use of TRESK-V3-VM as an intermediate point in accessing Targets from TRESK-Server.

Inner SSH tunnel(s) are created on demand inside the existing Outer SSH tunnel. This means that Inner SSH tunnel(s) are not persistent and are established only when there is a request from the PAM dashboard to access Target. After the PAM session ends Inner SSH tunnel(s) are closed.

Deployment considerations¶

System: Any OS capable of running Docker

Location: Intranet

Prerequisites:

• TRESK-V3-VM must be able to connect to the TRESK-Server
• Target must be accessible via TRESK-V3-VM.

TRESK-Client¶

This chapter describes the establishing secure connection between Target  and TRESK-Server via TRESK-Client. Basic principle is shown on Fig.1. Establishing secure connection between Target and TRESK-Server consists of two steps which are described later on this chapter:

1. SSH tunnel parametrer registration
2. SSH tunneling

Fig. 2. SSH tunneling using TRESK-Client

SSH tunnel parameter registration¶

This part is required because TRESK-Server needs to know details provided by TRESK-Client about SSH tunnels to be established, such as Organization ID, services which need to be routed inside SSH tunnels etc.

TRESK-Server endpoint for SSH tunnel registration is reachable under /registration via HTTPS on port 443. Messages are exchanged as JSON format described in Fig.3, Tab.1, Fig.4, Tab.2.

Tab.1 - TRESK-Client - SSH tunnel registration request message description

• Allowed entries under services are following (ports might change depending on client registration):

"ssh:22"
"vnc:5901"
"rdp:3389"
"web:80"

Fig. 3. TRESK-Client - SSH tunnel registration request message example

Tab.2 - TRESK-Server - SSH tunnel registration response message description

Fig. 4. TRESK-Server - SSH tunnel registration response message example

After the above request/response message exchange, a temporary user is created on the TRESK-Server. This user is used in further steps to establish SSH tunnel connection. After disconnecting the TRESK-Client from the TRESK-Server, the temporary user and all it’s trails are deleted from the TRESK-Server.

SSH tunneling¶

After initial request/response registration TRESK-Client establishes reverse SSH tunnel to TRESK-Server using ssh command. Basic principle is shown on Fig.5.

Fig.5 - Example of established SSH tunnel

In general the ssh command which establishes tunnel is composed from TRESK-server reply as following:

ssh  server.user@server.ip:server.port -R \ tunnels[0].remote_ip:tunnels[0].remote_port:tunnels[0].local_ip:tunnels[0].local_port

Regarding to exchanged messages above (Fig.2, Tab.1, Fig.3, Tab.2), ssh command in this case will be following:

ssh  user_1591962194949@192.168.195.130:2222 -R \ 192.168.195.130:5018:127.0.0.1:22

Deployment considerations¶

System: Windows 7 or later, Linux

Location: Target inside Intranet

Prerequisites:

• TRESK-Client must be able to connect to the TRESK-Server either directly or via firewall.
• Running TRESK-Client script does not require any special OS permissions nor any further OS dependencies.

Further materials¶

Excalibur Whitepaper

Excalibur FAQ

Excaliur Administrator Dashboard Manual