NetFoundry Platform Architecture
INTRODUCTION
SSH is a security protocol that every developer and administrator utilizes for connectivity to computers and servers. It provides a secure shell for login from one computer to another.
SSH needs access to the SSHD port before starting the authentication process which requires the port to be exposed to the network, exposing it to attack.
SSH also allows access via public key cryptography meaning an administrator can log onto the machine and “add a key” to a file that grants a user access. After a user leaves the company or becomes no longer authorized to access a server - this key needs to be removed from the system in order to deny access to the machine.
ZSSH is a program that takes the GO-based ZITI-SDK and uses the GO standard library to make a new “CLI” (command-line interface) allowing developers and administrators to use SSH/SCP over a ZITI network eliminating the port used by SSH from the internet-based firewall preventing any connections whatsoever from any network client. In this configuration, the SSH process is effectively "dark".
The only way to SSH to a machine configured in this way is to have an identity authorized for that Ziti Network through which the client securely connects to SSHD and SSH server.
With ZSSH's continual authorization through the use of policy checks, SSH access can be made more secure by preventing somehow who should no longer be able to access the machine at the ZITI network overlay layer.
In our Lab setup, the ZSSH application running from a remote user machine will have Zero Trust secure SSH access to Edge Route[running SSHD].
Pre-requisites :
1. The edge routers and endpoints need to reach the NetFoundry controller and NF-hosted edge routers for registration and operations. Please make sure to have the required ports, IPs, and URLs reachable if you have firewall ACL policies.
2. NetFoundry traffic should be bypassed from proxy or any deep packet inspection in between since it involves mTLS and E2E encryption.
The guide has the details.
https://support.netfoundry.io/hc/en-us/articles/4402361752717-Firewall-Requirements
The options in a Teams / Growth plan may vary. Refer to the support guide on creating a network on a Teams / Growth account.
For Enterprise accounts, follow the below steps:
- Log in to your NetFoundry Console at https://nfconsole.io/.
- Once logged in, you will be prompted to create your network.
- Give your network a name.
- Select the region where you would like to host your network (controller)
- Hit Create My Network to commence the provisioning of your network.
- It will take approximately 5-10 minutes for the network provisioning to complete. Once your network is ready, you will see the spinning globe icon turning green.
For additional information or assistance please see our Support Hub article Product v7-Create and Manage Networks.
Step 2 - CREATE EDGE ROUTERS
A) Provision a NetFoundry-hosted Edge Router
NetFoundry-hosted Edge Routers provide data transport as part of the fabric for endpoints and customer edge routers to dial to the fabric. At least one publicly accessible Edge Router is required for endpoints and edge routers to create a fabric. Having a min of two hosted ERs is a best practice for redundancy and smart routing.
NetFoundry-hosted Edge Routers provide data transport as part of the fabric for endpoints and customer edge routers to dial to the fabric. At least one publicly accessible Edge Router is required for endpoints and edge routers to create a fabric. Having a minimum of two hosted ERs is a best practice for redundancy and smart routing.
Provision a min of 2 NetFoundry hosted edge routers in the region strategic to Cloud Resources. Refer to the instructions for provisioning "NetFoundry-Hosted Edge Router" in the article.
Note that a new " Teams / Growth" account would have self-provisioned NetFoundry-Hosted Edge Routers based on the geo selected during the signup and the step can be skipped.
Snapshot of two NF-hosted routers provisioned in an enterprise account
To learn more about Edge Routers go to the Create and Manage Edge Routers article on the NetFoundry Support Hub.
B) Provision On-prem DC [Private Cloud] or any Public Cloud Customer Edge Router
Customer self-hosted Edge Routers (CERs) act as egress routers for endpoints / other CERs to reach the services terminated on the CER endpoint.
In our Lab setup, the ZSSH application running from a remote user machine will have Zero Trust secure SSH access to Edge Route[running SSHD] hosted in AWS.
Refer to the deployment guide below if you wish to provision a Customer-hosted Edge Router in a branch office or a Private cloud.
Create and Register AWS / Azure / OCI / any Public Cloud Edge Router
Use the below deployment guides to provision a Customer-hosted Edge Router into your AWS / Azure/ GCP/ OCI.
Step 3 - Creating a Service
The service definition provides the details of what device, or devices) will be utilized to provide access to services, either on the device(Zero Trust Client SDK Application) or on the network connected to the device (via its LAN, for example). The service also defines how the endpoints acting as clients to the service will access the service. Also, the service hosting details are provided.
- Ensure that POWER USER is ON for your user in the NetFoundry Console.
- From your Network Dashboard page, navigate to Services.
- Under the Services tab, click on the + sign at the upper right to add a service.
- Select “Advanced Configuration”.
-
Enter Information
-
Service Name: As desired.
-
Service Attributes: As desired.
-
Encrypt This Service:
YES
(ALWAYS!) -
Select Hosts For This Service: Find and select the GATEWAY created from PREREQUISITES.
-
Note that in the example an attribute (#) applicable to the GATEWAY identity is used.
-
-
Select the Edge Router Attributes Box:
#all
-
Select the HOST Config Box:
host.v1 / NEW CONFIG
-
Config Name: As desired.
-
Code:
{"port": 22,"address":"127.0.0.1","protocol":"tcp","listenOptions":{"bindUsingEdgeIdentity":true}}
-
Breakdown of Code:
-
port: IPv4 port: Instructs the SERVER endpoint to egress towards this port at the destination.
-
address: IPv4 or DNS resolvable record: Instructs the SERVER endpoint to egress towards this destination.
-
protocol: TCP or UDP: Instructs the SERVER endpoint to egress packets with the selected protocol.
-
listenOptions/bindUsingEdgeIdentity: TRUE or FALSE: How the CLIENT endpoint targets the SERVER endpoint.
-
-
-
-
Remove the INTERCEPT Config Box by clicking the red “X” in the top right corner of the box.
-
-
Select the “CREATE/UPDATE” button in the bottom right.
[NOTE] You will notice “127.0.0.1” in the “address” field of the Code section. This could also be a LAN-reachable server outside the localhost as well. We have chosen the localhost machine, i.e Edge router, which has SSHD, such that it was not necessary to instantiate another machine with SSHD.
[NOTE] When creating an “Advanced Configuration” Service, you will notice that the default screen presented has both the “host.v1” and “intercept.v1” configuration boxes presented. When an SDK-embedded application is utilizing this service to connect and receive data from the network, the “intercept.v1” config is not required and can be removed by selecting the “X” in the top right of the box. The same would be true for an SDK-embedded application that serves data to the network, however, in this case, the SSH SERVER does not have the SDK embedded within its code and therefore still requires the translation into IP performed by the ZITI Tunnel. Therefore, only one config designation is required to create a valid Service definition - the “host.v1” config applicable to the ZITI Tunnel.
Step 4 - Endpoint Creation and enrollment
- From your Network Dashboard page, navigate to Endpoints.
- Under the Manage Endpoints tab, click on the + sign at the upper right to add an endpoint.
- Give your endpoint a name.
- Give your endpoint an endpoint attribute. Endpoint attributes are tags applied to an endpoint. The same tag can be applied to other endpoints to form a group of endpoints.
- Hit Create to complete the process.
- You may download your registration key in .jwt file format or scan the client registration key QR code.
A) Download ZSSH
-
To download the binary, navigate to the following URL and select the link that is appropriate for your platform.
-
Once you have downloaded the binary of your platform, validate it runs after setting the permissions of the file. We have changed the binary name to “zssh” in our Lab.
-
Enroll the ZSSH CLIENT using the JWT file obtained from the NetFoundry Console. Note the identity file that is created is JSON. This file is extremely important and should be held in a private/encrypted/secured location on the machine.
-
./zssh enroll -j "path/to/enroll.jwt"
-
The ZSSH binary, utilizing the produced IDENTITY, is now well known to the network.
Step 5 - Creating an Edge Router Policy
Edge Router Policies - Defines specific Edge Routers for specific Endpoints (can be used for Network Transport segregation/optimization).
- From your Network Dashboard page, navigate to Edge Routers.
- Under the Edge Routers Policies tab, click on the + sign at the upper right to add a policy. An Edge Router Policy allows a specific endpoint or group of endpoints to have access to a specific edge router or group of edge routers.
- Give your edge router policy a name.
- In the Edge Router Attributes field, specify the edge routers to be associated with this policy. Use of edge router attribute will select all edge routers having that specific attribute.
- In the Endpoint Attributes field, specify the endpoints to be associated with this policy. Use of endpoint attribute will select all endpoints having that specific attribute.
- Hit Create to complete the process.
To know more about Edge Routers Policies go to the Create and Manage Edge Router Policies article on the NetFoundry Support Hub.
Step 6 - Creating an AppWAN
The AppWAN defines the services that can be accessed by one or more client endpoints.
- From your Network Dashboard page, navigate to AppWANs.
- Under the AppWANs tab, click on the + sign at the upper right to add an AppWAN.
- Give your AppWAN a name.
- In the Service Attributes field, specify the services or service attributes to be associated with this AppWAN.
- In the Edge Router Attributes field, specify the edge routers or edge router attributes to be associated with this policy.
- In the Endpoint Attributes field, specify the endpoints or endpoint attributes to be associated with this policy.
- Hit Create to complete the process.
Note: Use of endpoint/service/edge router attribute will select all endpoints/services/edge routers having that specific attribute. The @ symbol is used to tag Individual endpoints/services/edge routers and the # symbol is used to tag a group of endpoints/services/edge routers.
For additional information or assistance please see our Support Hub article Create and Manage AppWANs.
Step 7 - ZSSH in Action
Connect CLIENT/ZSSH to SERVER/SSHD (Endpoint to Endpoint, Zero Trust)
On the CLIENT, you should now have an identity file [JSON], Private key [.pem], ZSSH binary [zssh.exe]
-
Run ZSSH with the following syntax in the CMD - command prompt [if the Client machine is Windows]:
-
zssh -i "[PRIVATEKEY]" -c "[IDENTITY]" -s "[SERVICENAME]" "[USERNAME]@[SERVERNAME]"
-
Breakdown of syntax:
-
zssh
: The application which has the ZITI SDK built into it. -i "[PRIVATEKEY]"
: The PRIVATEKEY generated from AWS-
-c "[IDENTITY]"
: The IDENTITY created through enrollment (A JSON). -
-s "[SERVICENAME]"
: The Service name given in Console. -
[USERNAME]
: The username of a valid user on the destination/SERVER where SSHD resides -
@[SERVERNAME]"
: The SERVER (Endpoint)’s name given in the Console.
-
-
-