Netskope Help

Troubleshooting Tips and FAQs

This section provides information about common issues and suggested solutions.

The installation failed/hit a strange error. How do I get help?

Yes, please open a ticket with Netskope support and we’ll get an engineer to help you as soon as possible. Usually following the installation steps in this guide prevents most issues. If you do engage support, and you can access Cloud Exchange (the install got that far), please provide the following details with the ticket:

  • Download, install (requires ZIP command), and execute the Diagnose script found at https://github.com/netskopeoss/ta_cloud_exchange

  • If you have already installed a SSL certificate, two of the commands in the diagnose script will not work. If the UI is accessible:

    • Copy the exact version of cloud exchange and its components in use by CE. Go in your CE instance as follows: Go to Settings > General tab, Software version section.

    • Download the application's logs from your CE platform. Navigate to the Logging tab and click on the download icon.

  • Attach all output to the support ticket.

I received a Bad Gateway Error. What could cause this?

There are 3 possible causes

  1. Mongo data directory permission issue

  2. The Core/Mongo-DB container is down

  3. The CE maintenance password is incorrect

For possibility one, Mongo data directory permissions issue:

Verify

Execute ls -lRn . inside the directory with docker-compose.yml.

The mongo-data dir should be read/write accessible to the user with UID 1001.

./data/mongo-data:
total 0
drwxr-xr-x. 3 1001 0 16 Apr 14 18:16 data

Solution to mongo data directory permissions issue:

Execute the setup script again using ./setup to fix the file permissions.

Restart CE.

For possibility two, core/mongo-db container is down:

Verify

Check the container status using sudo docker-compose ps, all the containers should be Up.

$ sudo docker-compose ps
Name Command
State Ports
---------------------------------------------------------------------------------------------------------------- 
ce_330_core_1 /bin/sh start.sh Up 80/tcp
ce_330_mongodb-primary_1 /opt/bitnami/scripts/mongo ... Up 0.0.0.0:27018->27017/tcp ce_330_rabbitmq-stats_1 /opt/bitnami/scripts/rabbi ... Up 15671/tcp, 0.0.0.0:15672->15672/tcp, 25672 /tcp, 4369/tcp, 5551/tcp, 5552/tcp, 5671/tcp, 0.0.0.0:5672->5672/tcp
ce_330_ui_1 /bin/sh start.sh Up 0.0.0.0:443->3000/tcp, 80/tcp ce_330_watchtower_1 /watchtower --http-api-update Up 0.0.0.0:8080->8080/tcp

Solution to core/mongo-db container is down:

If any containers are down follow the below steps:

sudo docker-compose down
sudo ./start

For possibility three, the maintenance password is incorrect:

Verify

Check the core logs using `sudo docker-compose logs core` for any "authentication error".

Check if the customer is using CE version 3.2.0 or below 3.2.0 with the same MongoDB.

Solution to the maintenance password is incorrect:

Perform the following steps:

sudo docker-compose down
sudo rm -rf .env
sudo ./setup
Add maintenance password as "cteadmin"
sudo ./start
Although sharing is configured, the IoCs reported are not being shared with the threat source.

While sharing the IoCs to a particular plugin, the sharing filters provided with the plugin’s configurations are considered. Ensure that the sharing configuration matches with the IoCs you are expecting to be shared. If the sharing filter is incorrect, fix the sharing criteria. To fetch the historical data that you may have missed due to misconfiguration, consider removing the sharing configuration and re-adding it.

Netskope is rejecting some of the URLs Threat Exchange is pushing to it. Why?

Netskope only accepts URLs with wildcard characters that are in front of the domain, others will be rejected when Threat Exchange tries to send it. So *.google.com will be accepted by the Netskope tenant,but google.com/* will not. If your Threat Exchange database contains wildcards, you will need to manually tag to share.

Can I create new users apart from the default admin user?

Yes. Refer to Users.

Where are all the uploaded plugins stored?

By default, all your uploaded plugins are stored inside the ./data/custom_plugins directory. However, this can be changed from the docker-compose by mounting a different directory or the Admin can add an additional repository to download custom plugins from. This is configured within the Settings menu. This is the best method of adding additional plugins to your CE instance, and the only method for adding additional CTO, CLS, and CRE plugins.

How do I reset the user password if the current password is forgotten?

To reset the administrator password, refer to Reset Password in the Account Settings section. Make sure to change the password from Account Settings after the CE administrator has reset the password.

To reset any other user’s password, the Super Admin can update a user password from Settings > Users, and then click the Edit icon on the right.

The IoCs search performance is slow. It takes more than 5 seconds to load results.

The platform by default searches for the last 7 days of IoCs. If there are too many IoCs (more than 1 million) and no filter selected, the search performance will be slow.

Proposed solution : Consider applying the filters and narrowing the search criteria. Performance is best when the data set is ~100K records or less.

After upgrading/restarting the core and ui containers, the custom plugin configurations are not visible.
image81.png

Verify you uploaded a custom plugin with active configuration to Netskope CE prior to upgrading or restarting the containers. In such a case, upload the custom plugin after the upgrade (Refer to Create a Custom CTE Plugin in the Supported 3rd-party Plugins). The configurations would be retained after uploading the custom plugin and normal operation is restored.

While configuring a new plugin, even after providing accurate credentials, the configuration is not saved and an error message is displayed.

Verify if the outgoing API calls require a proxy. If your network deployment expects proxy for HTTP API calls and proxy is configured, the plugin operations would be impacted.

Proposed Solution:

  • Go to Settings > Proxy.

  • Edit the existing configuration and enable Use System Proxy.

image82.jpeg
Although the Poll interval for a plugin is configured to poll every 5 minutes, the Last Run shows an interval which is more than 5 minutes ago.

CE relies on an internal scheduling mechanism for the plugin's task. There are workers which execute the plugin tasks, by picking up a task from the queue one by one. The number of workers available in your system depends on the number of cores. If the available workers are busy serving plugin task, the already queued up task has to wait till the existing worker is available. This situation may usually occur during initial data ingestion, where there’s more data to be processed.

Proposed Solution: Consider increasing the cores of the system if you have a large number of configured plugins, and the configured plugins are consistently lagging behind. For initial ingestion, the system should pick up the backlog post initial ingestion and behave normally if the incremental data is not large.

A plugin configuration shows a red alert icon as shown below. What happened?
image83.jpeg

If there is a red alert icon on one of the configurations, it indicates that there was one or more problems while polling the plugged-in system for data per that configuration. This could be related to API, proxy, or SSL settings.

Proposed Solution:

  • Make sure the Plugin Configuration has correct parameters for API, Secret key, URL, etc.

  • Make sure Enable Proxy is selected and your proxy is configured if outbound network calls require a proxy connection.

  • Check logs for errors occurring around the last run time displayed on the configuration from the Audit section.

Mac OS users cannot select tar.gz while uploading a custom CTE plugin via the "Add Plugin" widget
image84.jpeg

When a user tries to upload a plugin with tar.gz package with the browse button, tar.gz files are not selectable by default.

Proposed Solution:

  • Drag and drop plugin packages to the drop area of the UI.

    image85.jpeg
How do I update the last run time of a plugin configuration? This is to replay the indicators in case they were missed.

Open the plugin configuration and set the Last Run value to an older date-time and save the configuration. Make sure that the configuration is currently not running when you update the Last Run value.

What kind of indicators are extracted from STIX/TAXII sources?

For STIX 1, the cybox observables of type URI, Domain, SHA256 and MD5 are extracted. For STIX 2, the same type of observables are extracted from the pattern string field of the indicators.

Even though a file in the repo is renamed, the comment on indicator still reflects the older file name.

This is a known limitation. Indicator comment is only added the first time that file is encountered. In subsequent runs, if the file is renamed, only the external hits will be increased as long (as the contents of the file remains same).

Ticket status is showing Deleted within Cloud Ticket Orchestrator even though tickets/incidents are not removed from 3rd-party platforms. Why?

This may happen if the API credentials used to create the tickets do not have access to the tickets anymore. Make sure that the credentials you are using have read access to the tickets.

How do I handle large repositories with the Github DLP Plugin?

When a Git repo contains a large number of files, a plugin configuration could timeout. The default timeout duration is set to 120 minutes. However, this can be increased by adding an environment variable in the docker-compose file.

core:
    image: crestsystems/netskope:core-latest
    container_name: "core"
    volumes:
    - ./data/custom_plugins:/opt/netskope/integrations/cte/custom_plugins:z
    environment:
    - PLUGIN_TIMEOUT_MINUTES=120
Log Shipper restarted or stopped. Why?

Log Shipper stops if something breaks, typically because of one of the following conditions are considered a failure: code race condition, core dump, process errors, or TCP socket errors. If CE receives 5 of these, it stops. Note that Log Shipper does NOT restart when it receives API errors, including the HTTP 200 error code, Response: {"status":"error","errorCode":"General Error","errors":["We encountereda backend error. Please try again."]}