Documentation
HomePortalStatus

Expose any TCP service

Suggest Edits

There are use cases where you may want to make any TCP service available through Border0. By doing so, you benefit from making the service available without the need for a VPN. As well as providing authentication and authorization rules using our policies.

We can do this by creating what we call a TLS socket. This type of socket is a MTLS service, forcing the client to authenticate and allowing the admin to forward authenticated users to any TCP service.

This type of socket can be used in, for example, the following cases:

  • RDP
  • VNC
  • Database (Where we don't do full inspection and recording)
  • SSH (Where we don't do full inspection and recording)

SSH Example

Border0 support SSH sockets, which allows us to proxy the SSH session, meaning we can do full SSH session inspection and recording. In some cases, you may not want us to look at this traffic, or the device you're trying to make available can't run the border0 client, or it doesn't support SSH certificates.

In this example, we'll start by making an TLS socket and connect it to our cloud. The service we're going to make available is an SSH port (22) on IP 192.168.12.109

border0 socket create --type tls --name tls-test
border0 socket connect tls-test --port 22 --host 192.168.12.109

Example:

$border0 socket create --type tls --name tls-test
┌──────────────────────────────────────┬──────────┬──────────────────────────┬─────────┬──────┬─────────────┐
│ SOCKET ID                            │ NAME     │ DNS NAME                 │ PORT(S) │ TYPE │ DESCRIPTION │
├──────────────────────────────────────┼──────────┼──────────────────────────┼─────────┼──────┼─────────────┤
│ 14a74c8b-ee23-4061-b01d-78e3b6f54789 │ tls-test │ tls-test-demo.border0.io │ 27231   │ tls  │             │
└──────────────────────────────────────┴──────────┴──────────────────────────┴─────────┴──────┴─────────────┘

Policies:
┌─────────────────────────┬─────────────────────────┬───────────────────┐
│ POLICY NAME             │ POLICY DESCRIPTION      │ ORGANIZATION WIDE │
├─────────────────────────┼─────────────────────────┼───────────────────┤
│ demo-org-default-policy │ Demo org default policy │ Yes               │
└─────────────────────────┴─────────────────────────┴───────────────────┘


$ border0 socket connect tls-test --port 22 --host 192.168.12.109


Connecting to Server: tunnel.border0.com

Welcome to Border0.com
tls-test - tls://tls-test-demo.border0.io

=======================================================
Logs
=======================================================

Ok, now it's connected, and the default policy has been attached.
Time for the next step, having end-users access the service.

Accessing the service

The easy way to connect to a generic TCP/TLS service is to have your border0 client connect to the Border0 cloud, authenticate with MTLS and start a localhost listener. After that, your client (RDP/VNC/DB/SSH) can connect to this localhost port.

Connecting to the service and starting a local listener can be done like this:

border0 client tls --host tls-test-demo.border0.io --listener 12345
2022/12/09 15:55:43 Waiting for connections...

Now i have a localhost listener on port 12345. I can use that to connect with my vnc/rdp/db/ssh client.
In our example, we used an SSH service, so let's connect to that with our ssh client

ssh testuser@localhost -p 12345

I'm now connected to the host 192.168.12.109 port 22, but through the Border0 platform. This worked because I have access according to the policy. So make sure your policy allows access.

checking the audit logs

Now we can check the session logs in the portal, and see all connections.

3104

Summary

In this example, we saw how using Border0, we can make any TCP service available using (M)TLS sockets. First, we created a Socket of type TLS. We then connected, during which we also configured what IP and Port we are making available.

Next up, on the client side, we made a local listener available on localhost. During this step, the client was also authenticated and authorized. This is to make sure the client actually has access. Finally, we were able to use our ssh client to connect to localhost, which tunneled the connection to the origin (192.168.12.109 port 22).

As the administrator, we could see exactly who accessed the TCP service, when, and from where.

SSH bonus

If you're using TLS sockets to make an SSH service available, then there's a nice trick to make this easier. By adding the following to your ssh config (~/.ssh/config), you don't need to start a local listener. You can just ssh directly to the socket.

Match host *border0.io exec "border0 client ssh-keysign --host %h"
  IdentitiesOnly yes
  IdentityFile ~/.ssh/%h
  ProxyCommand border0 client tls --host %h
  ServerAliveInterval 120
  ServerAliveCountMax 2

Now we can use the ssh command like this:

 ssh [email protected]

With this config in ~/.ssh/config, the ssh client with the use of the ProxyCommand, will automatically set up the (m)tls tunnel. Making the user experience easier for users.

Updated 10 months ago