Docy

Cloud Exchange Hardening

Cloud Exchange Hardening

The following sections provide guidance to make your Netskope Cloud Exchange tenants secure.

Host Hardening

CE runs on Docker on a Linux host. All best practices should be applied to harden the underlying host using CIS L1 benchmarks for either Ubuntu/CentOS or Red Hat Enterprise Linux.

System Wide Connectivity

The Netskope CE platform needs access to GitHub, Docker Hub, Netskope tenant, partners platforms and other 3rd-party platforms you wish to integrate with. Do evaluate network configurations like HTTP Proxy setup, Firewall rules, etc., to ensure the connectivity is available. The Netskope CE stack needs connectivity to these Public URLs.

For fetching third party plugins:

  • https://github.com

For fetching alerts and events from Netskope tenant:

  • https://*.goskope.com

For fetching web transactions from Netskope datalake:

  • https://*.googleapis.com
  • https://*.pubsublite.googleapis.com
  • Note: currently, Netskope web transaction logs are retrieved from http://us-west1-pubsublite.googleapis.com/ or http://europe-west3-pubsublite.googleapis.com/ However, these addresses are subject to change – thus the recommendation to use wildcards to ensure reachability

For reporting analytics to Netskope AWS service:

  • https://reporting.netskope.tech

For pulling docker images from Docker Hub (connectivity to additional hosts may be required since the docker images will be behind a CDN):

  • https://hub.docker.com
  • https://auth.docker.io
  • https://registry-1.docker.io
  • https://index.docker.io/
  • https://dseasb33srnrn.cloudfront.net/
  • https://production.cloudflare.docker.com/

If you are behind an HTTP or HTTPS proxy server, for example in corporate settings, you need to add the proxy configuration in the Docker systemd service file. Refer to https://docs.docker.com/config/daemon/systemd/#httphttps-proxy for details.

Firewall/Proxy Rules

System Wide Connectivity

The Netskope CE platform needs access to GitHub, Docker Hub, Netskope tenant, partners platforms and other 3rd-party platforms you wish to integrate with. Do evaluate network configurations like HTTP Proxy setup, Firewall rules, etc., to ensure the connectivity is available. The Netskope CE stack needs connectivity to these Public URLs.

For fetching third-party plugins:

  • https://github.com

For fetching alerts and events from Netskope tenant:

    • https://*.goskope.com

For fetching web transactions from Netskope datalake:

    • https://*.googleapis.com
    • https://*.pubsublite.googleapis.com
    • Note: currently, Netskope web transaction logs are retrieved from http://us-west1-pubsublite.googleapis.com/ or http://europe-west3-pubsublite.googleapis.com/ However, these addresses are subject to change – thus the recommendation to use wildcards to ensure reachability

For reporting analytics to Netskope AWS service:

    • https://reporting.netskope.tech

For pulling docker images from Docker Hub (connectivity to additional hosts may be required since the docker images will be behind a CDN):

    • https://hub.docker.com
    • https://auth.docker.io
    • https://registry-1.docker.io
    • https://index.docker.io/
    • https://dseasb33srnrn.cloudfront.net/
    • https://production.cloudflare.docker.com/

If you are behind an HTTP or HTTPS proxy server, for example in corporate settings, you need to add the proxy configuration in the Docker systemd service file. Refer to https://docs.docker.com/config/daemon/systemd/#httphttps-proxy for details.

Netskope IP Ranges

If you have conditional access enabled with vendors or SaaS apps for Netskope solutions, or need to SSL Allowlist by IP instead of domains, here is the list of Netskope consolidated list of IP addresses (for tenant access from Cloud Exchange in case your firewall does not support FQDN-based rules). Subscribe to this link by clicking the Follow icon on this page: https://support.netskope.com/s/article/NewEdge-Point-of-Presence-Data-Plane-and-Management-Plane-Global-Edge-Expansion-Status-and-IP-Range

Cloud Exchange Ports

Port Configurable? Description
443/80 Yes, during the setup script. Used to access the CE UI.
15672 No. Used to access the RabbitMQ dashboard.

Note that Cloud Exchange can be accessed via TLS 1.3 or 1.2 (as of 3.3.3). The choice of which version to use is configured via the setup script. Set TLS 1.3 and do not configure TLS 1.2 support.

Cloud Exchange Proxy

Cloud Exchange supports configuring a global proxy that can be used selectively as needed to communicate with external resources. Where a proxy is available for use, leverage the Cloud Exchange setup script tool (as of 3.3.3) to set the proxy globally.

Cloud Exchange Users

Default Username Default Password Configurable? Description
admin admin Yes, Can be changed during the first login. Used to access the Cloud Exchange UI.
user Yes, via Maintenance Password during the setup. Used to access the RabbitMQ dashboard.
cteadmin Yes, via Maintenance Password during the setup. Used to access the mongo database.

IdP Support

Cloud Exchange supports integrating with Identity Providers via SSO, though users can also be created locally on the box by the admin administrator that is logged in locally. There will only be one root admin. SSO should be the primary method of logging into CE, and where available, should leverage multi-factor authentication. There should be no other local users defined if possible.

Only users that require tokens should be provided roles that include token creation. Roles and users can be set up to have read-only only access. Use least privileged access to create roles with read-only access when possible for most users.

Password Management

There is currently no mechanism to enforce complex passwords or password expiration in Cloud Exchange. Again, SSO is expected to manage these advanced identity requirements. Account credentials should have an expiration and users should be prompted to reset their SSO password periodically.

The original admin should change its default password during the first session. If other users had to be defined locally, the administrator should periodically change their passwords via the GUI, although users can also be prompted to change their passwords manually in their own sessions via the Settings > Account > Change Password setting.

Managing Credentials

Credentials required for all Cloud Exchange operations are stored within the Mongo database. MongoDB is password protected. Authentication configured during the setup. The data stored within Mongo is unencrypted.

Note

Data encryption within Mongo is available in the Enterprise edition.

When creating an API token for CE to use to communicate, use least privileged access concepts. For now, a Netskope RESTful v1 API token must be installed for CE to communicate with Netskope (it is required for uploading file hashes for use in threat prevention and DLP policies) – it should be rotated on a regular basis. Netskope Cloud Exchange does use the v2 RESTful API endpoint for all other calls when it is provided. Create and provide a properly entitled v2 token.

The following privileges are required with the v2 token:

    • Read: /api/v2/events/data/network

    • Read: /api/v2/events/data/application

    • Read: /api/v2/events/data/page

    • Read: /api/v2/events/data/audit

    • Read: /api/v2/events/data/infrastructure

    • Read: /api/v2/events/data/alert

    • Read Write: /api/v2/policy/urllist/file

    • Read Write: /api/v2/policy/urllist

    • Read Write: /api/v2/policy/urllist/deploy

Encrypting Logs

The Logs managed by CLS are not persisted within CE during normal operations. The logs are fetched and transmitted over TLS communication.

In case of RabbitMQ paging out the messages to disk, the log messages would get stored on disk momentarily.

Table of Acronyms

Acronym Description
AD Active Directory
API Application Programming Interface
CE Cloud Exchange
CLS Cloud Log Shipper
CRE Cloud Risk Exchange
CTE Cloud Threat Exchange
CTO Cloud Ticket Orchestrator
CIS CIS benchmark standard
DLP Data Leak Prevention
IdP Identity Provider
SSL Secure Socket Layer
SSO Single Sign-on
TLS Transport Layer Security
UI User Interface

Share this Doc
In this topic ...