ZScaler is the Internet content filtering solution used in the Stokes County School District for all users accessing the Internet inside our District or from District owned devices, used off-site. All users are required to authenticate to the content filter system to gain access to the Internet. Guest Presenters to the Stokes County School District may obtain a day-use username and password from the Technology Department, upon request. Please see your site Media Coordinator or Principal to submit guest access request.
Zscaler is a Shareware software in the category Miscellaneous developed by Zscaler Inc. It was checked for updates 63 times by the users of our client application UpdateStar during the last month. The latest version of Zscaler is currently unknown. It was initially added to our database on. Download the ZScaler Certificate and save to your location choice (desktop, flash drive, etc). Open Internet Explorer. From Internet Explorer, go to the Tools menu, select Internet Options, and then in the window that appears switch to the Content tab and click the 'Certificates' button. Over 90% of websites now use TLS encryption (HTTPS) as the access method. Enterprises utilise TLS inspection for Advanced Threat Protection, Access controls, Visibility, and Data-Loss Prevention. Zscaler App is deployed on Windows and Mac devices and the Zscaler certificate is installed in the appropriate system Root Certificate Store so that the system/browser trusts the synthetic certificate.
Domain Joined Devices (Windows Desktop & Laptop computers) owned by Stokes County School District
NO USER ACTION NEEDED FOR DOMAIN JOINED DEVICES. Your ZScaler certificate and authentication cookie will automatically push down to your workstation, when you log into the CO domain. This is an automated process that occur's at login. You will NOT need to manually install the certificate to any District owned, domain joined computer. You will be prompted to login to the ZScaler login screen the first time you access the Internet, only once, from each new computer that you login to.
You will login to ZScaler using your Stokes County Domain user credentials as follows: [email protected]
When prompted for your password, you will enter the domain password (password that you use to login to the network at your school).
Personally Owned Devices
Personally owned devices are also required to authenticate to the ZScaler Content Filter, to gain access to the Internet. Users will be required to download and install the ZScaler root security certificate. This certificate is installed so that your Internet traffic can be securely transmitted. No data is collected from your computer, and no software or off-site monitoring capabilities are ever installed on personally-owned devices.
Before you install the certificate, you will need to download it to your computer. If you are using a Windows or Mac computer, save the file to your Desktop so that you'll be able to locate it later. Please refer to the installation instructions below, depending on your OS platform.
Below are the Instructions for manually installing the ZScaler Certificates to various Operating System platforms and Web Browsers for personally owned devices brought into our network.
Windows OS, using Internet Explorer web browser
Download all the ZScaler Certificate and save to your location choice (desktop, flash drive, etc).
Open Internet Explorer.
From Internet Explorer, go to the Toolsmenu, select Internet Options, and then in the window that appears switch to the Content tab and click the 'Certificates' button.
To install the certificate go to the Trusted Root Certification Authorities tab and click the 'Import..' button.
In the Certificate Import Wizard window that appears click the 'Next button.
To select the file, press the 'Browse..' button.
Find the saved certificate file (desktop, flash drive, etc.) and click the 'Open' button..'Next','Finish'.
The first time you open an Internet Page, you will receive a prompt from the Z-Scaler Web filter requesting that you authenticate. You will enter your Stokes Domain Username: [email protected]stokes.k12.nc.us (This will be the same 'format syntax' as your email address.)
This guide will cover deployment of a Nanolog Streaming Service (NSS) VM within Azure. NSS can also be deployed on-premise using an OVA file, or in AWS.
If you’re planning to integrate with Microsoft Cloud App Security (MCAS) or Azure Sentinel, you’ll require a healthy NSS deployment, and it is highly recommended that you use Azure.
Why do I need to deploy a VM to stream logs to a SIEM? Can’t Zscaler just send logs to my SIEM directly?
Your logs are stored in Zscaler’s Nanolog clusters in a highly compressed and encoded format. The NSS VM connects to both the Nanolog cluster and the Zscaler control plane, grabs the logs, decodes them, and forwards them to your SIEM over a TCP connection. Think of NSS as a log gateway!
You can’t follow this guide without an Azure subscription. If you’re deploying in as part of demo or lab environment, be careful: This guide WILL rack up some charges for VM and storage resources in Azure.
If you’re using the Azure Free Account, you should have US$200 of credit to use as part of your free subscription and may be able to avoid charges.
Proceed at your own risk.
Not all Zscaler subscriptions allow you to use NSS. In the ZIA Portal, navigate the Administration tab. If you don’t see Nanolog Streaming Service listed as an option, then you are most likely not subscribed to the NSS feature and will need to chat to your account team.
2 vCPUs (one for the control plane, one for the data plane)
Depending upon whether this is a lab/demo or production deployment, memory requirements (and hence, the Azure instance type you deploy on) will be different. A production deployment depends on the number of users ZIA is/will be deployed to:
Note: If you are planning on integrating with Microsoft Cloud App Security (MCAS), you MUST deploy with at least 8GB of memory. Using 4GB for a Lab/Demo environment will not work.
You’ll need the following information handy to deploy NSS in Azure:
If you have some or all of these already, you can skip forward as needed.
You need an Azure Subscription (even if it is part of the free tier) to continue. In the Azure Portal search bar (at the top of the page), search for “Subscriptions” and validate you have a valid subscription.
Ensure you have an existing subscription present, you click Add to create one if you need to.
Warning! You have the potential to rack up large charges if you aren’t careful! Proceed at your own risk!
A Resource Group houses related resources and services for something deployed in Azure.
If you don’t have a usable Resource Group already, you’ll need to create one. In the Azure Portal search bar (at the top of the page), search for “Resource Groups'.
Click Add to create a new one. Associate it with your subscription, give it a name, and select your closest Azure region.
In the screenshot above, the Resource Group I’ll be using is called
AzureLab, which is linked to the
Pay-As-You-Go subscription in the
Australia East region.
You’ll need (ideally) two Virtual Network (vNet) subnets to deploy NSS. In the Azure Portal search bar (at the top of the page), search for “Virtual networks'.
Click Add to create a new vNet (or select an existing one). If you’re creating a new one:
defaultsubnet - a /24 range which will be a subset of the /16 address space above. Leave this as it is and create a new /24 subnet. One of these will be for the management interface of the NSS VM, the other for the service interface.
In the image below, I have an vNet called
vNetLab which has a global 10.0.0.0/16 address space; with two subnets:
The Storage Account will house the VHD files for our NSS VM. In the Azure Portal search bar (at the top of the page), search for “Storage accounts'.
Click Add to create a new Storage Account.
Associate the Storage Account with your existing subscription and Resource Group. Provide it with a globally unique name. Ensure the location is the same as the one associated with your Resource Group.
For the cheapest option for a lab deployment, select the following:
Under the Networking tab, for a lab/demo deployment select Public endpoint (all networks): This will ensure you can immediately connect to the storage account. For a more secure deployment (ie: production), you might want to select either of the other two options.
Under the Data Protection tab, for a lab deployment, everything should be set to Disabled.
Under the Advanced tab, for a lab deployment, set everything as Disabled.
Click Review + create when you are done.
Open the Storage Account you just created, and in the left-side-menu, select Containers. Create two containers here: one will be used to copy the VHD files from Zscaler’s storage account, and the other will be used to deploy the NSS VM itself.
These are 32GB and 500GB respectively. Zscaler makes these available on their Storage Account which you can use to copy them across to your own to avoid transfer charges (not to mention the time of downloading & re-uploading that amount of data).
In this section, we will copy the two VHD images to the Storage Account and blob containers we created earlier, and then use these to initialize the NSS VM.
You can also do this via PowerShell, but that is outside the scope of this guide.
Download link (all platforms): https://azure.microsoft.com/en-us/features/storage-explorer/
Open Azure Storage Explorer, click the “plug” icon in the sidebar, then select Add an Azure Account. Click Next and you will be redirected to sign in to Azure via Microsoft SSO. Sign in using your Azure admin credentials.
Once you have logged in, you should see your Azure subscription in the side panel.
Next, we need to connect to the Zscaler Storage Account to access the NSS VHDs.
Click the plug icon again in the sidebar (as you did above), but this time select Use a shared access signature (SAS) URI.
Stop! You will need a SAS URI token from Zscaler to proceed!
You need a SAS token to authenticate with the Zscaler Storage Account. To obtain one:
Once you have your SAS token, you can fill in the fields in Azure Storage Explorer as prompted:
For example, for deploying in Australia, my full URI would look like:
Pay close attention to the format above as it is important. If you have an issue with Azure Storage Explorer not accepting the URI, check the formatting. Do not use any of the URLs provided to you ending in
Click Next when done, followed by Connect.
If you receive this error, it is most likely because your connection is being SSL inspected, and Azure Storage Explorer does not like this. You will need to add an SSL inspection bypass for
.blob.core.windows.net to resolve the issue.
For ZIA, navigate to Policy > SSL Inspection in the ZIA admin portal. Add
.blob.core.windows.net to the list of URLs to bypass from SSL Inspection. Save and activate your changes.
Wait a moment, then right-click on the storage account and click Refresh. If you just try and load the storage account again, you’ll continuously get the same error as it is cached.
The error should be resolved.
In the side panel of Azure Storage Explorer, expand the Zscaler NSS Storage (SAS) storage account, and select the nss blob container.
Select both of the VHD images listed and click Copy.
Next, under the Azure subscription you connected to earlier, expand the storage account you created earlier and select the blob container you created to store a copy of the VHD files. Click Paste and the files will begin to transfer. This is a 532GB file transfer so it may take a minute or two.
Note: You’re now consuming storage on Azure and there is a charge associated with this. Every region is different, but using the settings I selected above, my cost was estimated to be approx US$11 per month for a single blob container. This is just for storage. Using a 2nd blob container for the VM itself PLUS VM charges will get expensive quickly; particularly for a home lab deployment. You may wish to reconsider running this in a lab environment long-term.
In the Azure Portal, go to your storage account and look at the blob container you transferred the VHD files to. You’ll see them listed there.
Click on each file and copy the URL listed - we’ll need these later to deploy the NSS VM.
We need to use PowerShell to deploy the NSS VM via a script.
These modules let us perform tasks on Azure via PowerShell:
You’ll need to sign-in and authenticate using your Azure admin credentials:
Go to https://microsoft.com/devicelogin and enter the code provided.
Return to PowerShell and press Enter/Return. After a few moments your subscriptions will appear.
We need to grab the name of the Azure instance type we’ll be deploying the NSS VM on.
You can use the Azure Pricing Calculator to determine which instance type is best (and how much it will cost you). Be sure to select your region for accurate availability and pricing. Not every instance type is available in every region.
You’ll need an instance with 2 vCPUs and either:
If you’re not sure, just find something with 8GB of memory + 2 vCPUs.
Next, list all of the VM sizes for your selected region in PowerShell:
NB: The table above has been trimmed to fit.
Locate your desired instance, and copy down the name as it’s printed in the terminal window. We’ll need this for our PowerShell script which will deploy the NSS VM.
In my case, I’ll be using
Standard_A4_v2 which has 2 vCPUs and 8GB memory.
Be very careful! VM instances become expensive over a whole month! If left on for 30 days, the
Standard_A4_v2 instance type would cost be ~US$153! Proceed at your own risk!
The current Zscaler deployment script uses the old AzureRM modules which have been depreciated. We need to enable compatibility for them:
If you get an error similar to:
You’ll need to create the
powershell directly under
Allow powershell to run unsigned scripts (not needed/supported on macOS):
Copy the following into a file called
conf_file.txt and replace with your data:
A description of each of these fields is below:
|The name to be assigned to the NSS VM when deployed|
|The Azure region to deploy the VM to. This should be in lowercase with no spaces.|
|The name of the Resource Group to be used for VM deployment.|
|The name of the Storage Account to use.|
|The resource group that the vNet for the VM exists in. Will probably be the same as |
|The Azure vNet to which the VM should be attached.|
|The IPv4 address space assigned to the vNet in CIDR form. This will probably be the 10.X.X.X/16 range.|
|The name of the subnet you created within the vNet for the NSS management interface.|
|The subnet address prefix (in CIDR) of the subnet you created within the vNet for the NSS management interface. Could be 10.X.Y.X/24.|
|The name of the subnet you created within the vNet for the NSS service interface.|
|The subnet address prefix (in CIDR) of the subnet you created within the vNet for the NSS service interface. Could be 10.X.Z.X/24.|
|The number of NICs to assign to the VM. This should be set to |
|Set this to |
|The name of the Instance type/size to deploy the VM to (obtained above). Eg: Standard_A4_v2|
|The URI for your storage account. Remove the trailing |
|Name of the destination blob container within your storage account to create the VM disks. You would have created this in Part 2, Step 4.|
|The URI of the OS Disk .vhd file from your storage account that you copied in Part 3, Step 6.|
|The URI of the Data Disk .vhd file from your storage account that you copied in Part 3, Step 6.|
Download the NSS deployment script here:
Save the file as
deployment_script.ps1 in the same folder as the
conf_file.txt configuration file.
From the PowerShell prompt, run the deployment script. You may be prompted to sign in again:
When prompted, select the subscription to use, and (optionally) whether or not to use Public IP addresses for the two NICs. If this is a lab environment and you want to immediately be able to SSH to the NSS VM after deployment, you might want to select
y for this part.
Check whether the NSS VM has been deployed in the Azure Portal. In the search bar at the top of the portal, search for “Virtual Machines'. Validate that your new NSS VM is present and running.
If you chose to assign public IP addresses to your NSS VM during deployment, you may wish to lock this down with some rules to prevent anyone from being able to hit your VM.
As a start, you should only allow outbound connections to Zscaler’s required IP ranges. You can find these at the following URLs (depending on your Zscaler cloud):
You may also want to restrict inbound connectors to those on port 22 from your source IP only.
Apart from SSH management, NSS only requires connections to both the Zscaler Cloud and your SIEM/destination in the outbound direction. Not inbound connectivity is mandatory.
To create a security group, search for “Network security groups” in the Azure Portal. Click Add to create a new one.
You’ll need to then edit the security group, and apply it to the respective network interfaces created under the vNet in use by the VM.
For more information, see the Microsoft documentation, here.
Now that the NSS VM has been deployed, we need to configure it and associate it with our ZIA instance.
First, locate the IP address in use for the management interface. Under Virtual Machines in the Azure Portal, select the NSS VM, and on the Overview page, note either the Public or Private IP address assigned (under the Networking heading).
Review the NSS initial config to check whether the service interface has been configured correctly:
Default gateway for Service IP fields are blank, check the Networking menu of the NSS VM you deployed in Azure:
Note down the private IP of the 2nd network interface
<VMname>_nic_1, then run the
nss configure command to set the service interface IPs:
Sricam app for mac. When prompted, enter the IP address in CIDR format for the service interface (see above for formatting), and the IP address of the gateway for the service interface (if you use a /24 subnet, this will be the .1 IP address)
Download the SSL Certificate package for your NSS VM from the ZIA portal under Administration > Nanolog Streaming Service.
WARNING: This package is different for each NSS VM you have listed. Sharing the same certificate between NSS deployments will cause connection flapping.
Copy this package to the NSS VM:
Install the certificate package on the NSS VM:
Check the configuration:
If the SSL package was installed correctly, you will see your cloud name referenced in the configuration (eg: zscaler.net).
The NSS service on the fresh VM is probably out-of-date. To update it, run the
nss update-now command:
Updating may take some time…
You can check the current version with
To start the NSS service, run
This will NOT start NSS on boot by default. You should enable autostart:
To check active connections from NSS, run the following command:
NSS only requires outbound connectivity to the Zscaler Cloud and your SIEM/destination. No inbound connectivity is necessary (unless you’ve enabled SSH).
A healthy NSS instance will have two TCP connections in the
If you only see one connection, wait a few minutes and check again. If neither connection is in the
ESTABLISHED state, or you are still missing a connection, check your firewall and ensure you have reachability to the Zscaler infrastructure. You can check the network requirements for NSS using the links below (select the link corresponding to the Zscaler cloud you have been provisioned on):
Return to the ZIA portal, and under Administration > Nanolog Streaming Service, the NSS instance you just deployed should now read as Healthy:
NSS Feeds configured in the ZIA portal explicitly tell your NSS VM instance what data to stream, where to stream it, and in what format it is required.
Each NSS VM can be configured with up to 8 data feeds.
To configure an NSS Feed, go to Administration > Nanolog Streaming Service, then select the NSS Feeds tab. Click Add NSS Feed.
Fill in the following data when prompted:
|Name||The name of the NSS Feed|
|NSS Server||Which NSS VM is responsible for streaming this feed.|
|SIEM Destination Type||Select whether to use an IP or FQDN (domain) to specify the destination SIEM you would like to stream data to.|
|SIEM TCP Port||The destination TCP port the SIEM expects to receive data on.|
|Log Type||Typically you will want to select Web, but alerts can be streamed in RFC compliant Syslog as well.|
|Feed Output Type||The format (as shown in the window) that the logs will be streamed to the SIEM in (see the note below)|
|Filters||By default, the NSS feed will stream EVERYTHING. You can filter down the data stream to only specific data that you care about using the tabs at the bottom of the configuration window.|
Click Save when you are done and activate your changes.
Note that Zscaler has formal partnerships with several SIEM vendors, and in many cases has co-written deployment guides for them. If you don’t see your SIEM listed in the Feed Output Type, check to see if they don’t already have an article on Zscaler integration. Failing that, odds are they can probably ingest one of the existing formats; like QRadar LEEF, or Arcsight CEF.
Zscaler documentation covers how to configure feeds for a variety of features:
If you’re looking to integrate with Microsoft Cloud App Security (MCAS), I’ve written a detailed guide here.
You should now have a healthy NSS deployment in Azure.
If you deployed this for lab or demo purposes, make sure you don’t forget about the running NSS VM! Ensure you stop and de-allocate resources after you’re done so you don’t continue to be charged.