Thanks for signing up to Zentera Air!  You've now joined the growing ranks of administrators and developers who are simplifying access and securing private applications with Zero Trust.

 

About the Services

Zentera Air is an advanced SaaS Zero Trust network security platform that enables you to rapidly provide secure access to and security for applications. Zentera Air is divided into three product tiers, which allow you to select the level of access and security controls you need for your applications.

• Zentera Air Essentials supports basic Remote Desktop access (VNC/RDP) with DLP controls for copy/paste behavior
• Zentera Air Advanced is targeted at providing Zero Trust Network Access to private applications
• Zentera Air Ultimate adds Application Chambers, which help protect applications and data against  ransomware, data loss/leakage, insider threats, and other cyber attacks

Applications and servers can be anywhere – on-prem, in one or more clouds, or both.  A basic feature for all tiers is that access never needs open inbound firewall ports.

Your portal for management and control is hosted in Zentera's secure datacenters, while data traffic is carried either by our global network, or through providers of your choice.

 

About This Guide

This Getting Started guide for Zentera Air Ultimate will help you onboard and begin familiarizing yourself with the Zentera Air platform, through exercises and templates that will help you to familiarize yourself with the feature and controls. Once completing this guide, you should be able to

• Onboard users to Zentera Air Ultimate
• Create and assign user roles
• Onboard servers
• Create and manage access policies
• Understand Application Profile concepts and create new ones
• Understand the tools available for security and access log management

 

Getting Access to Zentera Air Ultimate

Once you sign up for Zentera Air Ultimate services, you'll receive an initial welcome email letting you know that your service is being provisioned.  Provisioning usually takes between 5-8 minutes, but can take longer depending on service load.

Once your service has been provisioned, you'll receive an email with your portal information and login credentials:

 

Make a note of your portal URL, as not only will you be using it not only to log in to the portal, your users will need this to access their services.

 

NOTE: custom portal URLs are currently not available in Zentera Air, but are planned for a future update. Please email us at air-support@zentera.net to be notified when custom portal URLs become available.

 

Click the "Login Now" button to open your portal in your browser.

 

For security, navigating to the base URL returns a 404. To reach your destination, you must append a path, for example: https://base-url/zCenter/  (admin portal login) https://base-url/launcher/ (CoIP Launcher)

 

Once you enter your credentials, you will be prompted to change your password and accept the Terms of Service and Privacy Policy before you can log in.

 

Navigating the Portal

The Portal Dashboard

The key elements of the portal dashboard are shown above:

1. The navigation menu enables you to quickly access pages that let you configure the users, applications, and access methods.
2. The Application Profile selector enables you to quickly move between different Application Profiles that you are managing.
3. The Segmentation Protection Scorecard gives you quick feedback on the security policies that are active in this Application Profile, and suggestions on how to improve them.
4. The Status View allows you to review the status of the various components of the Application Profile, as well as any alerts that may warrant review or action.

The Default Application Profile

Your Zentera Air tenant comes with a default Application Profile, named "Default App Profile", allowing you to onboard and test the core functions without having to learn much about how to configure them. Clicking on the Onboarding and Management > Applications tab on the navigation menu shows that two applications, App1 and App2, have been provisioned.

 

 

An application in the Zentera Air context represents a group of servers which will be managed with an identical set of policies – for example, a group of Apache servers might be one application, and a group of Tomcat servers might be a second application.  In the view above, you can see under "Servers" that we haven't onboarded any servers to either App1 or App2 yet.

If you've defined an access policy between these two applications, you can apply them to individual Apache or Tomcat servers simply by onboarding them into the correct application. In the Default App Profile template, we've defined a set of policies, as shown below. You can view these policies in your portal by navigating to Access Policy Management > Access Policies.

 

 

You can see that there are quite a few policies already defined for you. You may click on the edit button  to edit the access filter settings.  You may also use the slider controls  to enable or disable individual policies.

 

Onboarding Servers

Onboarding a server to Zentera Air is a simple process. You can download installation packages for your servers from the portal and run them on the server to be onboarded. This process can even be automated through APIs (which is outside the scope of this guide).

Generating the Installation Package

To onboard a server to an application, navigate to Onboarding and Management > Applications and click the download button  on the application you wish to onboard to. This brings up the following dialog:

 

You can download the package to your local machine, or simply generate a link which you can open on the target machine.  Generated links are valid for 15 minutes, so you must use them quickly after generating them.

 

 

To onboard a Windows server instead, select the Windows radio button to generate a Windows installer package.

 

 

Retrieving the Installation Package

You can copy the installation package link and paste it in the target machine to download the package. 

 

 

Installing zLink

Linux

Un-TAR and execute the installation script (must be run with administrator privilege), and the zLink agent (zasa) will be automatically set up and started.

 

 

Once zLink is installed and running, you will notice that the machine has a new virtual interface, called coip.  The details of setup and management of the coip interface are outside the scope of this document, but all secure remote access is provided through this virtual interface.

 

Before:

After:

 

NOTE: If you are installing the agent on a server, but have not yet configured any policies that require the CoIP interface, the coip interface will not be visible.  To verify whether the zLink agent is running, you may query the status of the service "zasa".   [centos@ip-10-180-0-194 ~]$ sudo systemctl status zasa ● zasa.service - Zentera Access Agent Loaded: loaded (/etc/systemd/system/zasa.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-11-19 08:01:39 UTC; 1 weeks 3 days ago Main PID: 9585 (zasa) Tasks: 6 CGroup: /system.slice/zasa.service └─9585 /usr/local/zasa/zasa -f -C /usr/local/zasa/zasa.cfg

 

Windows

To install on Windows, extract the installer to a folder, and then run the install script as shown below.  Do not attempt to run the installer without extracting, as the installation process may fail.

 

 

On Windows, the CoIP interface will appear as a new Ethernet adapter (172.24.1.1 in the example below).

 

 

Confirming Onboarding

You can confirm that the server is onboarded and registered to the zCenter portal by going to Onboarding and Management > Applications.  Now, we see that one server has been onboarded to the App1 application.

 

 

You can see detailed information about this server, including the Zero Trust factors that are gathered about this server, by clicking on the pencil icon () to the right of App1.

 

 

On this screen, click on the hostname to bring up the detailed view.  You may edit the Description field to tag the server with additional information.

 

 

Configuring User Accounts and Roles

The next step in setting up user access is to set up user accounts and roles.

 

User accounts are logins for individual users.  Credentials may be stored locally within the portal (a "local account"), or may be stored on your identity provider (that is, LDAP, SAML, OAuth, or OpenID Connect). Configuration of the identity provider is outside the scope of this guide.

 

User roles enable you to group users define assign role-based access controls to resources and applications.

 

Your portal comes with two pre-configured local accounts, testadmin and testuser, and two pre-configured user roles, "Standard Access" and "Admin Access".  These pre-configured accounts and roles are for your convenience during initial onboarding, and you may edit or delete as you begin to configure your own.

 

 

Username	Default Role(s)	Default Password
testadmin	Admin Access, Standard Access	test123
testuser	Standard Access	test123

 

You can view these users and roles under the Onboarding and Management > Users page.  Here, we can see that the Standard Access and Admin Access roles are configured for these users; based on the access policies that have been set up, these roles have been granted some access to resources in App1.  You can click on the role to view more information about the role, or click on the application to see details of the access policy.

 

 

Logging in to the User Portal

The User Portal provides your users quick links to access to all of the resources granted by their user role.  To log in to the User Portal is simple, browse to https://<base-url>/launcher/.  You will be prompted to enter your customer alias, which by default is your email domain.  For example, if you signed up for Zentera Air service with the email air-support@zentera.net, your customer alias will be zentera.net:

 

 

After entering the customer alias, you will be prompted to authenticate using your user credentials.

 

NOTE: Multi-Factor Authentication is not enabled for the default test accounts. You may configure the MFA method of your choice, including hardware tokens or passwordless authentication, when used with your corporate IdP.

 

Once you have authenticated, you will be prompted to download and install the CoIP Launcher 2.0 client. If you have enabled CoIP Access (VPN-style connectivity) for your users, they will be prompted to enter an administrator password; administrator run level is not required for desktop access.

 

 

 

After CoIP Launcher 2.0 is installed, your User Portal will display in your browser as shown below. In this case, the testadmin account has access to the "Default App Profile" Application Profile; you may also click the  button to the left to display the resources available for access.  If you have onboarded a server to the App1 profile, you should see it displayed in this list.

 

 

Sliding the Connect slider to the ON position will enable the user to connect to resources.  All connections are established on-demand, after the security context of the connection is authorized.  As shown below, the initial ping triggers the security re-evaluation, and has higher latency than the subsequent pings.

 

 

Once you have established this basic connectivity, you can edit the Access Policy definition, adding filters to restrict access based on the network protocol and port, the software process identity, or even the process tree to establish the desired level of security context.

 

Enabling Remote Desktop Access

Remote Desktop access to onboarded servers is managed through Access Policies.  You may create an Access Policy by navigating to Access Policy Management > Access Policies and clicking "Add Access Policy".

In the next page, select "Remote Desktop Access", give the policy a name, and select which User Role the policy will apply to.  If you wish, you can create dedicated User Roles to manage your Remote Desktop access separately from ZTNA private application access.

In the Access Control List section at the bottom, you will see a list of available servers in the window on the right; select the server to add to the policy and click  to move the server to the left window.

 

 

NOTE: You may select multiple servers at a time; you may also use the search fields or filters to narrow the list before you select servers.

 

Click "Next" at the bottom of the page.  This brings up the second step of Remote Desktop Access Policy configuration – configuring which Remote Desktop functions are supported.

 

Server Function

This selects between the Access Desktop or Access Server function.  An Access Desktop supports one concurrent user login, while an Access Server supports multiple concurrent user logins.

Connect View VNC/RDP

This option enables VNC or RDP access.  The appropriate access function will be selected based on the OS of the Access Desktop.

 

Select "Access Desktop" and "Connect View VNC/RDP" for the new Access Policy.  Configuration of the other options and modes are outside the scope of this document.

 

 

 

 

Using Remote Desktop Access

Users who a granted access to an Access Desktop will see that resource in the User Portal, as shown below.

 

 

Zentera Air supports multiple simultaneous VNC sessions; the user must first create a session using the "New Session" button, then enter the credentials to log in to the Access Desktop.  If the credentials are accepted, CoIP Launcher will launch a viewer, allowing the user to access the remote machine.

 

 

Enabling Application Chamber Protection

Zentera Air Ultimate enables you to protect applications against ransomware, insider threats, and other attacks by cloaking application servers in an Application Chamber.  An Application Chamber virtually segments the servers it protects by applying a set of consistent policies to all servers.

 

Application Chambers are configured through the Chamber Policy Management tab.

 

An Application Chamber may be in one of three modes:

Disabled – no policies are applied, and all security controls are turned off

Detection – policy violations are logged and reported, but not blocked

Protection – policy violations are blocked, logged and reported

 

Click the  icon to view the details of each Application's Chamber configuration.

 

Silo Mode defines whether servers inside the Application are allowed to communicate with each other.  In the example of a 3-tier web service, it might be unexpected for Apache web servers to communicate with each other; turning Silo Mode on will prevent this.

In all cases, inbound traffic to the Application Chamber is subject to a strict default-deny setting when the Chamber is in Protection mode.  This protects the servers in the Application Chamber against lateral migration from threats that may be in the corporate network, including hacking and ransomware. 

The Outbound Traffic setting provides a simple method to control the handling of outbound traffic.  The default setting is to allow all outbound traffic to all destinations; this allows servers to continue to originate network connections – software updates, for example.  However, this still allows an outbound connection to a remote command and control (C2) server; it also allows data to be exfiltrated by uploading to the Internet.  These threats can be blocked by selecting a higher level of outbound traffic security.

The "Allow non-whitelisted Local Network connections" setting blocks Internet-bound traffic by default.  Internet destinations may still be whitelisted by creating an appropriate Chamber Policy. Local network traffic is not filtered in this mode.

The "Deny all non-whitelisted connections" mode blocks all outbound traffic that is not exempted by Chamber Policy or an Access Policy.

 

The Default Chamber Template

A Chamber Template is a collection of Chamber Policies that are applied to the Application Chamber.  The Default Chamber Template is automatically instantiated for each new Application Profile.  All Application Profiles inherit changes made to the Default Chamber Template.  This gives you a simple control over the use of common services – defining a specific set of approved DNS resolvers allows you to block access to rogue local or Internet resolvers.

The Default Chamber Template is shown below.  Editing the Default Chamber Template or creating new Templates is outside the scope of this guide.

 

Changing the Chamber Mode

Once the Application Chamber has been configured with the appropriate settings, you may enable the Chamber by switching the Chamber Mode from Detection to Protection.  At this point, you should notice that all inbound access to the server in App1 is blocked, except for the Remote Desktop and ZTNA access you granted to users previously to authenticated and authorized users.  Outbound traffic from the servers in the chamber will follow the policies you selected.

 

Next Steps

Congratulations!  If you followed this Getting Started guide, you've just onboarded Access Desktops and granted access to them using User Roles.  You've also used and tested CoIP Access, enabling VPN-style network mode access to specific resources, and protected them against lateral attacks, insider threats, and ransomware using an Application Chamber.

 

At this point, you can use the Default App Profile to explore other functions.  Some ideas:

• Onboard a second server to the App2 application, and confirm unidirectional communication from App1 to App2
• Change the Access Policy settings, or create new ones, to explore the policy definition framework
• Create new Chamber Templates or customize the Default Chamber Template to apply to your organization
• Use Smart Discovery to automate the definition of Chamber Template policies, locking down application behavior to match existing behavior

Or, you could create your own Application Profile to test with some of your applications.

 

Getting Help

If you need help or clarification on any part of Zentera Air, feel free to contact us at support@zentera.net, or create a ticket in our support portal.