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.

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.
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.
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.
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.
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 tenant_support@netskope.com 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/Function	Description	Default Setting	Secure Setting
Secure email invites with one-time enrollment	Allows making email invites to be one-time use to prevent reuse.	Off	On
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.	Off	On
MFA (Settings > Manage > Multi-Factor Authentication Integration)	Enablement of multi-factor authentication. Integration with a third-party tool is required.	Off	On
SSO (Settings > Administration > SSO)	Enablement of SSO authentication using forms like SAML. Integration with a third-party tool is required.	Off	On
IP restriction for Tenant Access (Settings > Administration >IP Allowlist)	Controls the IP addresses that are allowed to access your Netskope tenant.	Off	On
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.	Off	On
Logging of Admin actions to SIEM	Logging of activity by admins is recommended but needs configuration by the user. Integration with a third-party tool is required.	Off	On

Traffic Steering

Feature/Function	Description	Default Setting	Secure Setting
Safe Search (Settings > Security Cloud Platform > Configuration)	Enforce strict safe search for queries sent to search engines.	On	On
Dynamic Trusted Store (Settings > Security Cloud Platform > Configuration)	Allows automatic download and use of intermediate certificate to verify server’s identity for SSL handshake.	On	On
Enhanced Cert-Pinned Apps	Allows using specific domains and process name combination before making a decision to bypass or steer traffic.	On	On
Bypass Loopback DNS controls	Allows configuring the Client to not respond to DNS responses from a DNS server on the Loopback address.	On	On

Error Settings in Steering Configurations

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

Feature/Function	Description	Default Setting	Secure Setting
Malformed SSL	Between 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.	Bypass	Block
No SNI	Between the Netskope Client and the Netskope Cloud Proxy, when the Netskope Cloud Proxy cannot determine the SNI.	Bypass	Block
Domain Fronting Protection	Between 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.	Bypass	Block
CRL/OCSP checks	Between the Netskope Cloud Proxy and the internet server, when the server’s certificate is revoked.	Bypass	Block
SSL Handshake Error	Between the Netskope Cloud Proxy and the internet server, when the SSL handshake fails.	Bypass	Block
Self-Signed Server Certificate	Between the Netskope Cloud Proxy and the internet server, when the server’s certificate is self-signed.	Block	Block
Incomplete Certificate Trust Chain	Between the Netskope Cloud Proxy and the internet server, when the server’s certificate chain is incomplete.	Bypass	Block
Untrusted Root Certificate	Between the Netskope Cloud Proxy and the internet server, when the server’s certificate is not trusted.	Block	Block
Malformed HTTP	Between the Netskope Client and the Netskope Cloud Proxy, when the HTTP request received by the Netskope Cloud Proxy is invalid.	Block	Block
SSL Host Mismatch	Between 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.	Block	Block

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/Function	Description	Default Setting	Secure Setting
Enable DTLS	Use only when required.	Off	Off, unless required.
On-premises Detection	If the endpoint is on-premise, the Client will tunnel the following types of traffic and this traffic is bypassed by the Netskope Cloud.	Off	Off
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.	On	On
Uninstall Clients automatically (Under Install & Troubleshoot)	Uninstalls the Client when users are removed from the Netskope tenant. Not recommended.	Off	Off
Allow users to unenroll (Under Install & Troubleshoot)	If the Client is provisioned via IdP, selecting this option allows users to unenroll from Netskope.	Off	Off
Allow disabling of Clients (Under Tamperproof)	Allows user to disable the Client on a device.	On	Off
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.	Off	On

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.

Updates

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 191.1.1.1/32 proto tcp port 784
ufw allow to 191.1.1.1/32 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 127.0.0.0/8
ufw deny in from ::1
ufw reload
sudo pkill npa_publisher

Note

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.

Change the default password to your admin accounts after you login to the appliance. To learn more: Log in to the Appliance.
Customize your login banner to include usage instructions or warning messages for the user. To learn more: Configure a Login Banner.
Use SSH keys for uploading OPLP logs. SSH keys provide a faster, easier, and secure way to access the appliance. Unlike passwords, SSH keys are difficult to brute-force hack due to the length and complexity of the keys. To learn more: Configure SSH Keys for Log Uploads.
Manage SSH connections to the appliance CLI by allowlisting IP addresses of trusted locations. To learn more: Manage SSH Connections by Allowlisting an IP.
Forward logs generated by the appliance CLI to your syslog or SIEM server. To learn more: Audit Events Generated by the Appliance CLI.
Allowlist only the required Netskope FQDNs. To learn more: Allowlist Domain Names for Log Upload.
Review Netskope's security advisories and vulnerability disclosures here, Security Advisories and Disclosures.

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.

Note

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:

Connect to the virtual appliance console.
Log into the virtual appliance using the credentials: nsadmin/nsappliance.

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

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.

To configure a login banner, enter the following command at the configuration prompt:
```
set system login-banner
```
Copy and paste the login banner at the prompt.
Press ctrl+D to set the new login banner.
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:

Access the appliance console using ssh.
Log in using the nsadmin/nsappliance credentials. An nsshell opens.
Enter configure to enter the nsshell configure mode.
Add an entry to the ssh-public-keys list in the CLI configuration:
```
add log-upload ssh-public-keys
added index 0
```

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
eVWDn8PJbniexq4PRvMy8RRYZ2ktu7aqacCjIpqlgbG0Xxgk5mXApXCpglqIE/A/
lRtZqfp6+/mbn7RuBbUXFkEbYz3uPwUFgZOUEI2KUx9za8SYnUc64kCujmYZ7UF5
JXmvZg4AhIPVHzvT+XbLDHOsC8mNrgEQeslpB9jGbCYZSLQKHwx3Pknv+rQaJ04G
+WRM/NmokhZXhM7GKXrufQjKRbZeXcHBGksNMSzTL+YihAQDqq4qC0drnGdu3Ezz
SEfwuz+PJ+ugh test@ubuntu-docker==
^D

To see the configuration, enter the following command:

show log-upload ssh-public-keys
[
  {
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCYr/tT64RNidYh
sLLQLdd2e1jDtxYepCcE0Z98iyzX57985XineoeVWDn8PJbniexq4PRvMy8RRYZ2
7aqacCjIpqlgbG0Xxgk5mXApXCpglqIE/A/ZD1lRtZqfp6+/mbn7RuBbUXFkEbYz
wUFgZOUEI2KUx9za8SYnUc64kCujmYZ7UF55a8JXmvZg4AhIPVHzvT+XbLDHOsC8
gEQeslpB9jGbCYZSLQKHwx3Pknv+rQaJ04GqiL+WRM/NmokhZXhM7GKXrufQjKRb
cHBGksNMSzTL+YihAQDqq4qC0drnGdu3EzzVRrSEfw test@ubuntu-docker==
"
  }
]

Enter save to activate your changes.
Enter exit to leave the configure mode.
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:

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 192.168.169.0/24,172.18.78.10

Enter save to save the configuration.

Limitations

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

Subnets must be specified in the format, <IP>/<Netmask>. For example, 192.168.169.0/24, 172.18.78.0/255.255.255.0.
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 172.17.0.0/16. 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, 192.168.1.0/0, 172.18.78.0/255.255.255.0.

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, only UDP-based syslog is supported.

To configure the syslog server destination:

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

Tip

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

Once enabled, review the log file on the system specified in the host and port commands.

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.

In this section:

Netskope Help