Secure Tenant Configuration and Hardening
The following sections provide guidance to make your Netskope tenants and Publishers secure.
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:
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 |
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.
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, TCP and UDP-based syslog are 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.
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.