This guide describes the tasks required to deploy a Nanolog Streaming Service (NSS) to stream either web logs or firewall logs to a SIEM. NSS can be deployed on Azure, Amazon Web Services (AWS), or on-premises on an ESX Virtual Machine. Each step in the guide links you to the appropriate article for that configuration task on Azure.
To learn more about NSS, see About NSS.
You'll need the following to deploy NSS over Azure:
The two public IPs aren't required when using a NAT. A NAT network configuration will work correctly as long as it has sufficient network bandwidth.
It's mandatory to deploy the NSS instance behind an Azure Network Security Group. The NSS instance requires only outbound connections to the Zscaler cloud. It doesn't require any inbound connections to your network from the Zscaler cloud. To view the firewall requirements for your specific account, go to the following:
The <zscaler-cloud-name> can be found in the URL you use to log in to the Zscaler admin portal. For example, if you log in to admin.zscaler.net, then go to https://ips.zscaler.net/addresses/nss.html.
The IP ranges are necessary to ensure that the service isn't affected by future Zscaler cloud expansion.
IP Addresses: The following table lists the IP addresses and the interfaces on which they're configured.
|Virtual Interface||IP Address||Description|
|nic0 (First network adapter)||Management IP Address||This is used for control connections to the Zscaler cloud and to make an SSH connection to the NSS VM for configuration and management. Note that you can customize the deployment and define a separate IP address for the SSH connection to the NSS VM.|
|nic1 (Second network adapter)||Service IP Address||This is used for data connections to the Zscaler cloud and to the SIEM.|
Second management or service network interfaces are currently not supported in the NSS over Azure VM deployment.
You can find more details about the outbound connection requirements on https://ips.<zscaler-cloud-name>/addresses/nss.html.
The NSS VM provisioning is done automatically using 2 PowerShell scripts.
Follow the next steps to configure and run the scripts:
The blob_copy.ps1 copies two VHD files from Zscaler’s Azure storage account to a destination account specified in copyconfig.txt. One VHD file is approximately 30GB and is used for the OS disk; the other is approximately 500GB and is used for the data disk. After copying the VHD files, the script will create an Azure Managed Image based on the OS Disk.
To complete this step, do the following:
To complete this step, do the following:
|osdisk||Use the appropriate link for your region:
|datadisk||Use the appropriate link for your region:
|sastok||Contact Zscaler Support or your account team to receive the SAS token|
|store||Destination Azure Storage account||mycompanyzscalerstore|
|name||Prefix for destination VHD file names||zscalernss|
|dest||Destination Blob Container Name in the destination storage account||zscalercontainer|
|rgname||Creates or selects a Resource Group with this name||zscaler_rg|
|location||The Azure location for the destination container||westus|
For the value location, the following are all the possible location names:
To get the latest location list, run the following PowerShell command:
Get-AzureRmLocation | Format-Table
|eastus2||East US 2|
|northcentralus||North Central US|
|southcentralus||South Central US|
|westcentralus||West Central US|
|westus2||West Central US 2|
|australiacentral2||Australia Central 2|
|name||Name of the instance||zscalernss
Used also for the NIC prefix. Identical to the one used in the blob_copy.ps script.
|location||Location to deploy the instance||westus|
|rgname||Name of destination resource group||zscaler_rg|
|createrg||N if the resouce group is allocated already. Y if it needs to be provisioned.||N|
|storename||Name of the destination storage account||mycompanyzscalerstorage|
|createstorage||If storage account is already provisioned, set this to N. Set everything else to Y.||N|
|vnetname||Name of the virtual network to which this instance is associated. Creates a VNET if the one with specified name doesn't exist.||zscalernss_vnet|
|vnetprefix||IP address range in CIDR for the virtual network||10.0.1.0/24|
|subnetname||Name of the subnet in virtual network to which this instance is associated. Creates a new subnet if one with this name doesn't exist.||zscalernss_subnet|
|subnetprefix||CIDR prefix for the subnet||10.0.1.0/24|
|niccount||Number of NICs to attach to the instance||2, unless advanced deployment|
|datadisksize||If create option is selected, set the size of disk to be created. Size is in GB.||500|
|srcDataURL||If attach option is selected, set to the data disk VHD URL|
|srcOsURI||URI of the OS disk copied in the previous step.||Go to Image Overview > Source Blob URI to find the URI|
|dstStorageURI||URI of the storage account to which the OS and Data disks are copied to. The URI should not include the ending forward slash.||Go to Storage Account > Primary Blob Service Endpoint to find the URI|
|dstContainer||The name of the container to which the OS and data disks are copied to||zscalernsscontainerprod|
The NSS service configuration steps will be executed through an SSH terminal connection to your instance. SSH to NSS only works with basic authentication. Use zsroot/zsroot when prompted for credentials. We recommend that you change the default password.
Before starting, do the following:
To configure the NSS virtual appliance on Azure, follow the steps below.
NSS uses an SSL certificate to authenticate itself to the Zscaler service. Ensure that the SSL certificate is installed on only one active NSS Azure VM at a time. Having multiple NSS Azure VMs that use only one certificate causes cloud connection flapping, which disrupts the streaming of logs to the NSS.
On NSS on Azure, the first network interface (management network) is configured by default when you spin up the Azure VM.
An NSS feed specifies the data from the logs that the NSS will send to the SIEM. You can filter the data, so you send only the data you need to the SIEM. You can add one or more fields for the logs and one field for alerts. You can add up to eight NSS feeds for each NSS. Each feed can have a different list of fields, a different format, and different filters. Click a link below to learn how to configure each feed.
You can also learn about:
For full site redundancy, each organization can subscribe to up to two NSS servers for each type of traffic and deploy each pair in an active-active configuration. Each NSS supports up to eight parallel feeds. Each feed can have a different list of fields, a different format, and different filters.
When you register a new NSS in the Zscaler service, you are required to download an SSL certificate, which you then upload to the new NSS that you configure. The newly configured NSS then uses the certificate to authenticate itself to the Zscaler service. You can configure one NSS as two virtual machines identified by the same certificate, as long as they do not try to connect to the Nanolog at the same time. One VM can be the active NSS and the other VM can be a cold standby. Zscaler strongly recommends against running both VMs as active because this will result in frequent connection resets and a failure to stream the logs.
For completely redundant site configurations, if your organization has two SIEMs, Zscaler recommends using two NSS subscriptions, so both NSS VMs can stream logs to the SIEMs at the same time. Each NSS will run independently, with different configurations, and stream logs to two separate SIEMs. This is not recommended if you use a single SIEM, because each NSS will send copies of the same logs to the SIEM, which might not be able to remove the duplicates.