Secure Tenant Configuration and Hardening

Secure Tenant Configuration and Hardening

The following sections provide guidance to make your Netskope tenants and Publishers secure.

Platform Security

This document describes how to secure a tenant by checking and changing settings for features and functions in the Netskope UI.

Tenant Access

The following steps explain how to quickly set up your tenant.

  1. Set up a global admin that will only be used with proper change management controls. Log in to Netskope and go to Settings > Administration > Admins > New Admin. For more info, see: Create Administrators.
  2. Enable Single Sign On (SSO) with your current SSO provider. Log in to Netskope and go to Settings > Administration > SSO. For more info, see: SSO Settings.
  3. Create and assign roles for restricted admins. Log in to Netskope and go to Settings > Administration > Roles. For more info, refer to Create Roles and Assign Roles.
  4. Identify any non-corporate users in the administration list and remove or revoke access. Log in to Netskope and go to Settings > Administration > Admins. For more info, refer to Change Access.
  5. Confirm your enterprise policy for tenant support and enable or revoke based on the policy. Log in to Netskope and go to Settings > Administration > Admins. Identify and review your corporate policy regarding this tenant support user and their level of access. Use the slide bar to the left which allows enablement and/or removal of this account. For more info, refer to Managing Administrators.

Some default settings should be changed to secure a Netskope tenant.

Feature/FunctionDescriptionDefault SettingSecure Setting
Secure email invites with one-time enrollmentAllows making email invites to be one-time use to prevent reuse.OffOn
Disallow concurrent logins by an Admin

(Settings > Administration > Admin > Settings)

Ensures an admin can log in to a tenant only once, instead of being able to log in to a tenant multiple times concurrently.OffOn

(Settings > Manage > Multi-Factor Authentication Integration)

Enablement of multi-factor authentication. Integration with a third-party tool is required.OffOn

(Settings > Administration > SSO)

Enablement of SSO authentication using forms like SAML. Integration with a third-party tool is required.OffOn
IP restriction for Tenant Access

(Settings > Administration >IP Allowlist)

Controls the IP addresses that are allowed to access your Netskope tenant.OffOn
Chromebook Verified Access

(Settings > Security Cloud Platform > Reverse Proxy > SAML. Click on your Google Account and select Options.)

Use to verify if the Chromebook is enrolled via Verified Access.OffOn
Logging of Admin actions to SIEMLogging of activity by admins is recommended but needs configuration by the user. Integration with a third-party tool is required.OffOn
Traffic Steering
Feature/FunctionDescriptionDefault SettingSecure Setting
Safe Search

(Settings > Security Cloud Platform > Configuration)

Enforce strict safe search for queries sent to search engines.OnOn
Dynamic Trusted Store

(Settings > Security Cloud Platform > Configuration)

Allows automatic download and use of intermediate certificate to verify server’s identity for SSL handshake.OnOn
Enhanced Cert-Pinned AppsAllows using specific domains and process name combination before making a decision to bypass or steer traffic. OnOn
Bypass Loopback DNS controlsAllows configuring the Client to not respond to DNS responses from a DNS server on the Loopback address. OnOn
Error Settings in Steering Configurations

These settings are located at: Settings > Security Cloud Platform > Steering Configuration > Manage Error Settings.

Feature/FunctionDescriptionDefault SettingSecure Setting
Malformed SSLBetween the Netskope Client and the Netskope Cloud Proxy, when the designated port is 443 but fails to parse the first packet in the SSL traffic.BypassBlock
No SNIBetween the Netskope Client and the Netskope Cloud Proxy, when the Netskope Cloud Proxy cannot determine the SNI.BypassBlock
Domain Fronting ProtectionBetween the Netskope Cloud Proxy and the internet server if domain fronting is detected. Netskope detects domain fronting when the SNI and HTTP request Host header are mismatched.BypassBlock
CRL/OCSP checksBetween the Netskope Cloud Proxy and the internet server, when the server’s certificate is revoked.BypassBlock
SSL Handshake ErrorBetween the Netskope Cloud Proxy and the internet server, when the SSL handshake fails.BypassBlock
Self-Signed Server CertificateBetween the Netskope Cloud Proxy and the internet server, when the server’s certificate is self-signed.BlockBlock
Incomplete Certificate Trust ChainBetween the Netskope Cloud Proxy and the internet server, when the server’s certificate chain is incomplete.BypassBlock
Untrusted Root CertificateBetween the Netskope Cloud Proxy and the internet server, when the server’s certificate is not trusted.BlockBlock
Malformed HTTPBetween the Netskope Client and the Netskope Cloud Proxy, when the HTTP request received by the Netskope Cloud Proxy is invalid.BlockBlock
SSL Host MismatchBetween the Netskope Cloud Proxy and the internet server, when the domain name of the server doesn’t match the common name in a server’s certificate.BlockBlock
Client Configuration

The Netskope Client installation links via the on-boarding process has an activation key. This activation key is generated when the on-boarding email is sent to the user. When a user clicks on an installation link, the activation key in the link validates the link and allows the Netskope Client installer to download from the download service. The installer has an activation key along with other user and tenant info.

These settings are located at: Settings > Security Cloud Platform > Devices > Client Configurations.

Feature/FunctionDescriptionDefault SettingSecure Setting
Enable DTLSUse only when required.OffOff, unless required.
On-premises DetectionIf the endpoint is on-premise, the Client will tunnel the following types of traffic and this traffic is bypassed by the Netskope Cloud.OffOff
Upgrade Client automatically

(Under Install & Troubleshoot)

Clients will automatically upgrade to the specified Client release. Recommendations are:
  • Group: Suggested Configuration
  • InfoSec/Test Ring: Latest Golden Release
  • General/Default Config: Specific Golden Release – Opt-in dot upgrade. Suggest selecting the latest Client version that was validated via the test ring.

Disabling the Show Upgrade Notification option is recommended.

Uninstall Clients automatically

(Under Install & Troubleshoot)

Uninstalls the Client when users are removed from the Netskope tenant. Not recommended.OffOff
Allow users to unenroll

(Under Install & Troubleshoot)

If the Client is provisioned via IdP, selecting this option allows users to unenroll from Netskope.OffOff
Allow disabling of Clients

(Under Tamperproof)

Allows user to disable the Client on a device.OnOff
Password protection for Client uninstallation and service stop.

(Under Tamperproof)

Password protection to prevent stopping the services is only supported on the Client on Windows.OffOn

Publisher Configuration and Hardening

Netskope provides prebuilt Publishers for VMWare (OVA format), Hyper-V (VHDX), Azure (VHD), and AWS (AMI).  Additionally, you can also deploy a Publisher on top of a Ubuntu 20.04 based machine for other environments, such as GCP.  The deployment methods and use of Docker images may raise some concerns about hardening and security.  This document provides info that can be used by customers under NDA to better understand how a Publisher is deployed and maintained.

OS Requirements

Ubuntu 20.04 is supported.

Significant changes from the previously supported CentOS-based machine are:

  • Ubuntu Publishers are CIS benchmark enabled.
  • AppArmor and ufw are used instead of SELinux and FirewallD.
OS Hardening

Netskope takes a number of hardening steps for the images we provide including:

  • Disabling root login to base OS and container OS.
  • Removing root password.
  • Removing unneeded Linux firmware and packages.
  • Running the latest security updates prior to capturing the image.
  • Disabling support for CTL-ALT-DEL to prevent accidental or malicious system restarts.

You can perform additional hardening steps, such as:

  • Hardening SSH to use keys rather than passwords. AWS AMI uses keys by default. Publishers deployed on other platforms must be manually configured to use keys.
  • Using the native Ubuntu 20.04 firewall or network firewalls to limit access to and from the Publisher.

Netskope Private Access leverages RSA 2048 for all encrypted communications including Client, Publisher, and inner tunnel.


Netskope updates the host OS and the Publisher package during the software update process:

  • Base OS ( Ubuntu 20.04) security updates.
  • Publisher (security, functionality, and enhancements).

Netskope recommends that Publishers should always be updated to the most recent software version.

AppArmor and ufw for Ubuntu

The NPA Publisher is configured with AppArmor and ufw enabled and running. During Publisher installation, the following ufw configurations are made in order to enable the NPA Publisher to process data packets appropriately.

apt-get install -y ufw
echo y | ufw enable
ufw allow to proto tcp port 784
ufw allow to proto udp port 785
ufw allow in on tun0 to any port 53 proto tcp
ufw allow in on tun0 to any port 53 proto udp
ufw allow 22/tcp
ufw allow in on lo
ufw deny in from
ufw deny in from ::1
ufw reload
sudo pkill npa_publisher


As indicated above, this configuration is applied automatically in all current NPA Publisher releases and is included here for reference/legacy Publishers.

Appliance Configuration and Hardening

This document guides you to run your appliance in a secure manner. Follow the security checklist to secure your appliance.

Log in to the Appliance

The appliance has two different command prompts:

  • <hostname>: This is the nsshell prompt.
  • <hostname>(config): This is the configuration prompt (nsshell prompt in configuration mode).

You can login to the appliance using one of the two admin user accounts, nsadmin or nstransfer. The nsadmin user account has the privilege to operate and configure the appliance. Whereas the nstransfer user account can be used to upload logs from the appliance using protocols like SFTP, SCP, or FTP.


Netskope recommends that you set a new password for nsadmin and nstransfer user accounts to secure your appliance. To learn more: Change the Appliance Password.

Change the Appliance Password

When setting up a new password for your appliance, follow the best practices, such as:

  • Set a password with a minimum length of 12 characters.
  • Include upper-case and lower-case alphabets, number, and special characters.
  • Change passwords every 90 days.
  • Do not reuse old passwords.

To change your appliance password:

  1. Connect to the virtual appliance console.
  2. Log into the virtual appliance using the credentials: nsadmin/nsappliance.
  3. Change your password by using the following command.
    nsappliance> auth change-password nsadmin
    New password: <newpassword>
    Retype new password: <newpassword>
    passwd: password updated successfully
    nsappliance> auth change-password nstransfer
    New password: <newpassword>
    Retype new password: <newpassword>
    passwd: password updated successfully
  4. At the nsshell prompt, enter configure to go into configuration mode. The command prompt changes to the nsshell configuration prompt (<hostname>(config)).
Configure a Login Banner

When you log into your virtual appliance, the default login banner for the Netskope Appliance is displayed in the console. You can secure the appliance by customizing the login banner to display custom instructions and warning messages for the user.

  1. To configure a login banner, enter the following command at the configuration prompt:
    set system login-banner
  2. Copy and paste the login banner at the prompt.
  3. Press ctrl+D to set the new login banner.
  4. To save the login banner configuration, enter save at the configuration prompt.
Configure SSH Keys for Log Uploads

You can configure your SSH key pairs to automatically upload logs to the appliance.

To use your own SSH key pairs:

  1. Access the appliance console using ssh.
  2. Log in using the nsadmin/nsappliance credentials. An nsshell opens.
  3. Enter configure to enter the nsshell configure mode.
  4. Add an entry to the ssh-public-keys list in the CLI configuration:
    add log-upload ssh-public-keys
    added index 0
  5. Set the value of the ssh public key at the index returned from the last command. This requires you to paste the SSH public key:
    set log-upload ssh-public-keys 0 key
    Copy and paste the ssh public key
    Enter one or more lines of input. When done, press Ctrl-D
    ssh-rsa ABAQCYr/tT64RNidYhuGisLLQLdd2e1jDtxYepCcE0Z98iyzX57985Xi
    SEfwuz+PJ+ugh test@ubuntu-docker==
  6. To see the configuration, enter the following command:
    show log-upload ssh-public-keys
        "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCYr/tT64RNidYh
    cHBGksNMSzTL+YihAQDqq4qC0drnGdu3EzzVRrSEfw test@ubuntu-docker==
  7. Enter save to activate your changes.
  8. Enter exit to leave the configure mode.
  9. Enter exit to leave the nsshell and exit the appliance console.
Manage SSH Connections by Allowlisting an IP

SSH connections to access the appliance CLI can be restricted to trusted IPs only. This configuration ensures that only allowlist IPs can access the appliance CLI.

To configure allowlist IPs on an appliance:

  1. In the configuration mode, type the command,
    set system ssh-allowlist <comma-separated list of IPs and subnets without spaces>

    For example,

    set system ssh-allowlist,
  2. Enter save to save the configuration.

When configuring allowlist IPs on an appliance, ensure the following:

  • Subnets must be specified in the format, <IP>/<Netmask>. For example,,
  • Individual allowlisted IPs in the list cannot be the same as IP addresses that are configured on the appliance’s interfaces. Although, allowlisted subnets are allowed to contain IP addresses configured on the appliance’s interfaces.
  • Allowlist IPs must not contain the subnet reserved for Netskope appliance’s internal bridge network. By default, the appliance’s internal services use the subnet This subnet can be changed using the command,
    set system bridge-network <IP subnet>

    When specifying a new subnet for the bridge network, use the format <Network Address>/<Netmask>. For example,,

Audit Events Generated by the Appliance CLI

You can audit various actions taken on the appliance, such as all shutdown and startup events, all login/logout attempts, SSH connection attempts from an IP address that is not allowlisted (see Manage SSH Connections by Allowlisting an IP ), and all commands executed by the users on the nsshell (except configure and exit). All commands are logged whether or not they succeed.

As a security measure, you can forward all the appliance command logs to your syslog or SIEM server. Currently, TCP and UDP-based syslog are supported.

To configure the syslog server destination:

  1. Open nsshell to the appliance and enter these commands:
    add audit-logging destinations
    #{server response should be} added index 0
    set audit-logging destinations 0 host <hostname>
    set audit-logging destinations 0 port <port number>
    set audit-logging destinations 0 protocol [TCP | UDP]
    set audit-logging enable true


    Enter false in the last command to turn off this feature.

  2. Once enabled, review the log file on the system specified in the host and port commands.
Output Format
<Date> <Time> <Syslog Facility> {"user": <username>, "cmd": <log message or command>, "mode":<auth | config | op>} 
  • Date: Date
  • Time: Time
  • Syslog Facility: We are using 14 which is “log alert”
  • cmd: This depends on the “mode” (see next).

    If the mode is “auth”, cmd contains the log message related to authentication activity (log in, log out). If the mode is “config” or “op”, it shows the actual CLI command run. 

  • mode: Tells which mode the command is being run. These modes are available:
    • auth: representing activity as per /var/log/auth.log (log in attempts etc.)
    • config: CLI mode that allows user to configure various settings
    • op: OP mode representing operational commands like show, restart, status etc.
Allowlist Domain Names for Log Upload

To process logs using the Netskope Appliance OPLP feature, the OPLP feature requires only a few FQDNs to be allowed for it to work. From a security standpoint, a best practice is to follow the minimum access principle, and only allow access to the required domains.

Netskope recommends that you use domain names instead of IP addresses when configuring firewall or proxy rules for allowlisting.

The complete list of Netskope’s outbound domain names is available in the “Outbound Ports” section of Virtual Appliance Overview.

Share this Doc
In this topic ...