The following sections provide guidance to make your Netskope Cloud Exchange tenants secure.
Host Hardening
Cloud Exchange 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 or Red Hat Enterprise Linux. To watch an HA setup video, click play.
Secrets Manager
When configured, you can configure Netskope tenants, custom plugin repositories, and plugins using secrets from your configured Secrets Manager.
System Wide Connectivity
The Cloud Exchange 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 Cloud Exchange stack needs connectivity to these Public URLs.
For fetching third party plugins: https://github.com
For fetching alerts and events from Netskope tenant: https://*.<tenant-domain>
For fetching web transactions from Netskope Log Streaming, refer to these guides:
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
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. |
| 8000 | No. | Used by Cloud Exchange management server to get virtual machine resource utilization and setup proxy and HA configuration using TLS communication. |
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 4.x) to set the proxy globally.
HA Hardening
- In order to establish the necessary connectivity between Docker services across various machines and facilitate the integration of nodes into the cluster, we have exposed the ports listed below from the Docker services. It is imperative that these ports remain accessible from all machines where the Cloud Exchange HA deployment is intended. To enhance security measures, it is also advisable to restrict access to these ports from other IP addresses.
These ports will be used for the clustering of the MongoDB and RabbitMQ services. Also the UI ports are required to perform a health check from all the machines.
Port
Configurable?
Description
443/80
Yes, during the setup script.
Used to access the CE UI.
4369
No
A peer discovery service used by RabbitMQ nodes and CLI tools.
5672
No
Used by AMQP 0-9-1 and AMQP 1.0 clients without TLS.
15672
No
HTTP API clients, management UI and rabbitmqadmin without TLS.
25672
No
Used for inter-node and CLI tools communication.
35672
No
Used for inter-node and CLI tools communication.
27017
No
The default port for mongodb and mongos instances.
5761
No
Used by AMQP 0-9-1 and AMQP 1.0 clients without TLS.
15671
No
HTTP API clients, management UI and rabbitmqadmin without TLS
24007-24029
No
Glusterfs ports used for inter node communication, health checks, selfheal demon, brick communication
8000
No
Used by Cloud Exchange management server to get virtual machine resource utilization and setup proxy and HA configuration using TLS communication.
- GlusterFS installation and setup will be driven through the Cloud Exchange UI and management server, which will act as shared storage and will also have HA capabilities. All the VMs involved in the HA cluster should have connectivity to GlusterFS repo during HA configuration.
Cloud Exchange as VM Hardening
The default user is cteadmin; cteadmin has full sudo privileges and can execute any command as root after providing the password.
OVA
- It does not require docker or github connectivity to setup the Cloud Exchange mandatorily.
- Maintenance password will not be visible in .env file once it has been set while configuring Cloud Exchange.
- Default cteadmin user can run only predefined set of commands with sudo privileges.
- The cteadmin user can execute sudo commands after providing cteadmin password.
AMI
It does not require docker or github connectivity to set up the Cloud Exchange mandatorily.
Azure
It does not require docker or github connectivity to set up the Cloud Exchange mandatorily.
CE API Rate Limiting (UI to Backend)
- Cloud exchange is restricted to serve 100 API requests per seconds.
- This rate limit is only applicable for Cloud exchange UI to Backend communications.
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. |
User Lockout Mechanism
- Users are allowed up to 5 login attempts.
- If a user fails to log in within these 5 attempts, they will be locked out of their account for a duration of 2 minutes.
- With each successive set of 5 attempts, the lockout duration will increase incrementally.
- For the second set of 5 failed login attempts, resulting in 10 unsuccessful attempts, the lockout duration will be 5 minutes.
- After three sets of 5 failed login attempts, resulting in 15 unsuccessful attempts, the user will face a more extended lockout period of 6 hours.
- For every set of 5 consecutive attempts, until the user successfully logs in, the lockout period will be 6 hours.
- Once the user successfully logs in, the cycle will continue.
Strict Password Policy for the Cloud Exchange User
- Password must contain at least one lower case letter
- Password must contain at least one uppercase letter
- Password must contain at least one special character (e.g #, @,)
- Password must contain at least one numeric character
- Minimum 8 characters are required for the password
- Maximum 72 characters are supported for the password
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
The following privileges are required with the v2 token:
- Read + Write /api/v2/policy/urllist
- Read + Write /api/v2/policy/urllist/deploy
- Read + Write /api/v2/policy/urllist/file
- Read + Write /api/v2/incidents/uba/getuci
- Read + Write /api/v2/ubadatasvc/user/uci
- Read /api/v2/events/dataexport/events/alert
- Read /api/v2/events/dataexport/events/application
- Read /api/v2/events/dataexport/events/audit
- Read /api/v2/events/dataexport/events/connection
- Read /api/v2/events/dataexport/events/incident
- Read /api/v2/events/dataexport/events/infrastructure
- Read /api/v2/events/dataexport/events/network
- Read /api/v2/events/dataexport/events/page
- Read /api/v2/events/dataexport/alerts/compromisedcredential
- Read /api/v2/events/dataexport/alerts/ctep
- Read /api/v2/events/dataexport/alerts/dlp
- Read /api/v2/events/dataexport/alerts/malsite
- Read /api/v2/events/dataexport/alerts/malware
- Read /api/v2/events/dataexport/alerts/policy
- Read /api/v2/events/dataexport/alerts/quarantine
- Read /api/v2/events/dataexport/alerts/securityassessment
- Read /api/v2/events/dataexport/alerts/uba
- Read /api/v2/events/dataexport/alerts/watchlist
- Read /api/v2/events/dataexport/alerts/device
- Read /api/v2/events/dataexport/alerts/content
Encrypting Logs
The Logs managed by Log Shipper are not persisted within Cloud Exchange 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 |
| ARE | Application Risk Exchange |
| CE | Cloud Exchange |
| CLS | Cloud Log Shipper |
| 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 |
| URE | User Risk Exchange |