icon-zia.svg
Secure Internet and SaaS Access (ZIA)

NSS Deployment Guide for Google Cloud Platform

Zscaler’s Nanolog Streaming Service (NSS) supports the configuration and deployment of an NSS virtual machine (VM) on Google Cloud Platform (GCP).

After configuring and deploying an NSS VM on GCP, you can stream your organization’s Web or Firewall logs from the Zscaler cloud to your security information and event management (SIEM) system.

The following guide describes the deployment procedure with sample configurations

Prerequisites

Before you begin deployment, you must get access to the Zscaler-owned NSS VMDK file. To get access, contact Zscaler Support.

You must also have a Google Cloud Storage bucket so that Zscaler can share the file, and so that you can retrieve the file from storage during deployment. To learn more about creating Google Cloud Storage buckets, refer to the Google Cloud documentation.

Additionally, ensure you have a subscription to either NSS for Web or NSS for Firewall and review the following specifications and requirements:

  • You create a VM instance as a step in the deployment procedure. The VM must meet the following requirements:

    • vCPUs: 2 vCPU (1 shared core)
    • CPU speed: Greater than or equal to 2.40GHz
    • Instance memory:
      • 8 GB for up to 8K users
      • 16 GB for up to 20K users
      • 32 GB for up to 50K users
      • 48 GB for up to 75K users
      • 64 GB for more than 75K users

    The following VM specs are recommended:

    • Machine family: General purpose
    • Boot disk type: Standard persistent disk
    • Boot disk size: 500 GB

    To learn more about machine types, refer to the Google Cloud documentation.

    Close
    • Two network interfaces: You create two network interfaces as a step in the deployment procedure.
      • The first network interface is the management IP address. It is used for control connections to the Zscaler cloud and to make an SSH connection to the NSS VM for configuration and management. You can customize the deployment and define a separate IP address for the SSH connection to the NSS VM.
      • The second network interface is the service IP address. It is used for data connections to the Zscaler cloud and to the SIEM.
    • Two public IP addresses: The two public IP addresses are not required when using a NAT. A NAT network configuration works correctly as long as it has sufficient network bandwidth.
    • Bandwidth for log download: 11 Mbps for 10K users is an example average value.
    Close

  • It is mandatory to deploy the NSS VM instance behind a network security group. The NSS VM 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, refer to the Zscaler configuration requirements for your Zscaler cloud: https://config.zscaler.com/<Zscaler Cloud Name>/nss.

    You can find the name of your Zscaler cloud in the URL that you use to log in to the Zscaler service. For example, if you log in to admin.zscaler.net, then go to https://config.zscaler.com/zscaler.net/nss. To learn more, see What Is My Cloud Name for ZIA?

    The Zscaler Hub IP address ranges are necessary to ensure that the service isn't affected by future Zscaler cloud expansion.

    Communication from the NSS to the Zscaler cloud must be excluded from SSL inspection to ensure that the NSS can authenticate to the Nanolog cluster using mutual TLS.

    Zscaler does not recommend or support forwarding outbound traffic from the NSS to or through the ZIA Public Service Edge as this can result in networking, latency, and administration issues.

    Close

Deploying NSS

To deploy NSS:

    1. Go to Administration > Nanolog Streaming Service.

    2. From the NSS Servers tab, click Add NSS Server.

      The Add NSS Server window appears.

    3. In the Add NSS Server window:

      • Name: Enter a name for the NSS server.

      • Type: NSS for Web is selected by default. To add an NSS server for Firewall logs, select NSS for Firewall.

        If you have a subscription to Cloud & Branch Connector, the NSS for Firewall (NSS type) is displayed as NSS for Firewall, Cloud & Branch Connector.

      • Status: The NSS server is Enabled by default.

    4. Click Save.

      The NSS server is added to the ZIA Admin Portal.

    5. Click Download in the SSL Certificate column of the newly added NSS server, and then save the SSL certificate. You later copy the SSL certificate to the VM instance.

      Close

    Close

  • A Nanolog Streaming Service (NSS) feed specifies the data from the logs that the NSS sends to the security information and event management (SIEM) system. You can filter the data so that you send only the data you need to the SIEM. You can add up to 16 NSS feeds for each NSS server. (Web and Firewall logs are each limited to 8 feeds per NSS server to ensure optimal performance.) Each feed can have different filters and fields, and a different output format (e.g., CSV). To learn more about how to configure each feed, see:

    When adding the feed, note the SIEM IP address and TCP port for later verifying the NSS-to-SIEM connection.

    Close

  • With the Zscaler-owned NSS VMDK file in your Cloud Storage bucket, you can use the Google Cloud console to import the VMDK file into Compute Engine as a custom image.

    To create an NSS image from the VMDK file:

    1. Go to Compute Engine > Images.

    2. Click Create Image.

      The Create an image page appears.

    3. On the Create an image page:
      1. Name: Enter a name for the image.
      2. Source: Select Virtual disk (VMDK, VHD).
      3. Virtual disk file: Browse to and select the Zscaler-owned NSS VMDK file in your Cloud Storage bucket.
      4. Operating system on virtual disk: Select No operating system. Data only.
      5. Cloud Build service account: Select the appropriate service account.
      6. Log location: Enter the source URI of your Cloud Storage bucket (e.g., gs://<bucket>/).

      7. Install guest packages: Enable this setting.

      8. Click Create to start the import process.
    Close

  • To create a VM instance with the NSS image:

      1. In the Google Cloud console, go to VPC Network > VPC networks.

      2. Click Create VPC Network.

        The Create a VPC network page appears.

      3. On the Create a VPC network page:
        1. Name: Enter a name for the VPC network (e.g., nss-test). This first network is later used for assigning an internal IP address to the first network interface (i.e., the management interface). The management IP address is used to control connections to the Zscaler cloud and to make an SSH connection to the NSS VM for configuration and management.
        2. Maximum transmission unit (MTU): Zscaler recommends 1460.

        3. Subnet creation mode: Zscaler recommends Automatic, which creates a subnet in each region. If you want to manually define subnets, select Custom. To learn more about subnet creation mode, refer to the Google Cloud documentation.

        4. (Optional) In the Firewall rules section, you can select from existing firewall rules if they are appropriate for the VPC network. To learn more, see the Firewall Requirements section. If you want to configure new rules, you can configure a firewall policy and associate it with the VPC network in the subsequent step. For example, if you are creating custom subnets, you can create an appropriate firewall policy to manage them.
        5. Click Create.
      4. Repeat the previous steps to create the second VPC network (e.g., nss-test2) for assigning an internal IP address to the second network interface (i.e., the service interface). The service IP address is used for data connections to the Zscaler cloud and your SIEM.
      Close
      1. Go to VPC Network > Firewall.

      2. Click Create Firewall Policy.

        The Create a network firewall policy page appears.

      3. On the Create a network firewall policy page:

        1. In the Configure policy section, enter a name for the firewall policy, and then click Continue.

        2. In the Add rules section, create and add firewall rules for incoming (ingress) and outgoing (egress) traffic according to your organization’s policies, and then click Continue. To learn more about creating firewall rules, see the Firewall Requirements section and refer to the Google Cloud documentation.

        3. In the Associate policy with VPC networks section:

          1. Click Associate.

            The Associate policy with VPC networks panel opens.

          2. On the Associate policy with VPC networks panel, select the VPC networks that you created (e.g., nss-test and nss-test2), and then click Associate.

            Close

        4. Click Continue.
        5. Click Create.
      Close
      1. Go to Compute Engine > Images.

      2. Select the NSS image that you created, and then click Create Instance.

        The Create an instance page appears.

      3. On the Create an instance page:
        1. Name: Enter a name for the instance.
        2. Region: Select the region for the instance.

        3. Zone: Select the zone for the instance.

          Close

        4. In the Machine configuration section, select a machine that meets the requirements in the VM Specs section. The following image shows an example of a machine that meets the requirements:

        5. In the Boot disk section, ensure your appropriate boot disk Type (e.g., Standard persistent disk) and Size (e.g., 500 GB) are configured. If not, click Change and configure.

        6. In the Advanced options > Networking section:
          1. IP forwarding: Enable this setting.

          2. Network interface card: Select VirtIO.

          3. Network interfaces: Add two network interfaces: the first as the management interface, and the second as the service interface. To add the two network interfaces:
            1. Network: Select the network that you created for the management interface (e.g., nss-test).
            2. Subnetwork: Select an appropriate subnetwork.
            3. Primary internal IPv4 address: Select Ephemeral (Automatic) to allocate an internal IP address from the subnet range. Select Ephemeral (Custom) to manually enter one.

            4. External IPv4 address: Select Ephemeral to assign an external IP address from a shared pool. Alternatively, you can use a reserved static external IP address. To learn more about network interface IP address allocation, refer to the Google Cloud documentation.

            5. Click Done.

            6. Click Add a Network Interface and add the second network interface, configuring the network (e.g., nss-test2), subnetwork, and internal and external IP addresses for the service interface.

              After creating the network interfaces, the management interface is assigned to vtnet0 and the service interface is assigned to vtnet1, as shown in the configuration file in the subsequent step.

        7. Click Create and wait for the VM instance to be provisioned.
      Close
    Close

  • To configure and start the NSS on the VM instance:

      1. Go to the newly created VM instance (Compute Engine > VM Instances) and connect via SSH or the Serial Console, if connecting to serial ports is enabled.
      2. When prompted, enter the username and password (e.g., zsroot / zsroot).

      3. Open the /etc/rc.conf file to verify the following configuration:

        #configurable per-machine info goes here (vtnet0 is mgmt and vtnet1 is service int)
network_interfaces="lo0 vtnet0 vtnet1"
ifconfig_vtnet0="UP"
ifconfig_vtnet0="DHCP"
ifconfig_vtnet0="SYNCDHCP mtu 1460"

        The configuration confirms that there are two network interfaces (i.e., management and service), and that the management interface (i.e., vtnet0) is working as expected. If the configuration is not present in /etc/rc.conf, add it to the file and save, and then run the following command to restart the service:

        /etc/rc.d/netif restart
      Close
      1. Copy the downloaded SSL certificate to the VM instance.

      2. Run the following command to configure the NSS:

        sudo nss configure

      3. When prompted, enter the following IP addresses:

        • Nameserver IP address
        • Internal service IP address associated with the service interface
        • Default gateway for the internal service IP address

        The following configuration is an example. Replace the values in red with the IP addresses for your deployment:

        [root@nss /usr/home/zsroot]# nss dump-config
Configured Values:
CloudName:zscalerthree.net
nameserver:169.254.169.254
Mgmt IP:
Default gateway for Mgmt IP:
Internal Mgmt IP:
route_net:
Service IP Address:/dev/tap0:192.168.4.13/24
Default gateway for Service IP:192.168.4.1
Routes for Siem N/w:

      4. Run the following command to install the SSL certificate:

        nss install-cert <certificate>

        Replace the parameter in red with the SSL certificate file name (e.g.,
        NssCertificate.zip) if you are in the path of the file. If not, use the file path (e.g., /usr/home/zsroot/NssCertificate.zip).

        The NSS uses the SSL certificate to authenticate itself to the Zscaler service. Ensure that the SSL certificate is installed on only one active VM at a time. Having multiple VMs that use only one certificate causes cloud connection flapping, which disrupts log streaming.

      5. Before starting the NSS, run the following command to download and install the NSS binaries:

        sudo nss update-now

        After the first NSS software deployment, the software is automatically updated with new versions.

      6. Run the following command to start the NSS:

        sudo nss start

        The NSS starts within a few minutes.

      Close

    • To verify the NSS configuration, run the following command:

      sudo nss troubleshoot netstat | less

      The output of the command shows the following TCP connections:

      • Connection to the Zscaler cloud on port 443: This is the control connection that is used to authenticate the NSS to the Zscaler Central Authority (CA) and to download the configuration. It is also the data connection to the Zscaler Nanolog so that it can stream the logs.
      • Connection to the SIEM: This is the long-lived TCP connection to the SIEM on the specified log data port (e.g., 192.168.0.3.34561). If there are multiple feeds configured, then multiple connections must be listed.

      The following image shows a sample output verifying the TCP connections are established:

      Troubleshooting

      If the NSS connection with the Zscaler CA fluctuates (i.e., it is established and then disconnects), run the following command:

      ifconfig vtnet1 -rxcsum -txcsum -rxcsum6 -txcsum6 -tso4

      If the NSS connection with the SIEM is not established:

      1. Add smnet_route in the /sc/conf/sc.conf file, replacing the following parameters shown in red with the values for your deployment.

        smnet_route=<SIEM IP Address>/32/<SIEM Gateway IP Address>

        The following is an example: smnet_route=192.168.0.2/32/192.168.4.1

      2. Run the following command to restart the NSS service:

        sudo nss restart

      Zscaler recommends adding a custom route in the sc.conf file if your downstream SIEM IP address is in the same subnet.

      Close
    Close

Post-Deployment Tasks

After you have verified your deployment, you can perform additional tasks:

  • You can use the following commands within the virtual machine (VM) console for your platform in order to configure and troubleshoot the NSS server. By default, root login is not permitted, so admins must use the sudo utility to run a command with higher privileges.

    • To start the service:
    sudo nss start
    • To stop the service:
    sudo nss stop
    • To restart the service:
    sudo nss restart
    • To smoothly shut down the operating system:
    sudo nss halt
    • To change the network configuration (i.e., IP addresses, gateway information) for the service:
    sudo nss configure

    To learn more, see the NSS deployment guide for your platform.

    • To configure additional interfaces:
    sudo nss configure split-interface

    To learn more, see Configuring the Additional Interfaces from the Console.

    • To configure an explicit proxy:
    sudo nss configure proxy

    To learn more, see Configuring NSS in Explicit Proxy Mode.

    • If you configured additional interfaces using the sudo nss configure split-interface command and want to remove the configuration:
    sudo nss configure split-interface --wipe
    • To remove the network settings that were configured using the sudo nss configure command:
    sudo nss configure --wipe
    • To display the configuration file that was changed using the sudo nss configure command:
    sudo nss dump-config
    • To install NSS certificates from a specified certificate bundle file:
    sudo nss install-cert <certificate bundle file>
    • To check if a new NSS version is available:
    sudo nss checkversion
    • To manually update the NSS to the latest version:
    sudo nss update-now
    • To force the NSS to update, regardless of whether a new version is available:
    sudo nss force-update-now
    • To check the firewall configuration:
    sudo nss test-firewall

    This command does active firewall configuration probing by attempting to resolve the DNS names and establishing outbound connections to the Zscaler cloud. This command doesn't reset the management IP interface, so you can run it on an SSH connection.

    • To view troubleshooting help command information:
    sudo nss troubleshoot help
    • To show the active connections on the service IP address:
    sudo nss troubleshoot netstat

    The output is similar to that of the netstat utility.

    • To show the connections and their status:
    sudo nss troubleshoot connection

    This command probes the connection status over a period of time and indicates whether the connections are stable or flapping.

    • To show the status of the NSS feeds:
    sudo nss troubleshoot feeds

    This command probes the status of the feeds and determines if the logs are queued due to the slow consumption of logs by the security information and event management (SIEM) system.

    • To generate diagnostic information to send to Zscaler Support:
    sudo nss collect-diagnostics

    This command collects the configuration, vital statistics regarding the health of the NSS, and error statistics, and then downloads the data to a local file. This file can be emailed to Zscaler Support for troubleshooting purposes.

    • To reset the network configuration:
    sudo nss reset-network
    • To change the SNMP admin user configuration:
    sudo nss snmp-admin-configure
    • To change the SNMP trap configuration:
    sudo nss snmp-trap-configure
    • To automatically start the NSS after reboot:
    sudo nss enable-autostart
    • To disable the automatic start of the NSS after reboot:
    sudo nss disable-autostart
    • To set up and enable MCAS:
    sudo nss configure-mcas2

    You must restart the NSS using the sudo nss restart command for the changes to take effect. To learn more, see Integrating with Microsoft Cloud App Security.

    • To disable MCAS:
    sudo nss disable-mcas

    You must restart the NSS using the sudo nss restart command for the changes to take effect. You can re-enable MCAS by re-issuing the sudo nss configure-mcas2 command.

    Enabling Remote Access

    An admin can request remote assistance and allow Zscaler Support to log in to their NSS server without having to open a firewall connection for inbound traffic. This feature is disabled by default and must be enabled explicitly for the duration that remote support assistance is required.

    • To enable Zscaler Support to access your NSS server:
    sudo nss support-access-start

    This creates a long-lived SSH tunnel to the Zscaler cloud and sets up remote port forwarding. Zscaler Support can then use this tunnel to log in to your NSS server.

    • To disable Zscaler Support access to your NSS server:
    sudo nss support-access-stop

    This brings down the long-lived SSH tunnel to the Zscaler cloud and all the remote connections.

    • To check the status of the Zscaler Support access to your NSS server:
    sudo nss support-access-status

    This checks the status of the long-lived SSH tunnel to the Zscaler cloud, which Zscaler Support uses to log in to your NSS server.

    • To enable a remote debugging session:
    sudo nss enable-remote-debugging
    • To disable a remote debugging session:
    sudo nss disable-remote-debugging

    Error Codes

    The following are error codes that you might encounter when executing an sudo nss update-now command:

    Error CodeDescription
    Error Code 96Invalid client certificate
    Error Code 97Timeout occurred while contacting upgrade server
    Error Code 99A problem occurred while downloading and installing the latest version. The sudo force-update-now command needs to be explicitly issued.

    Use Case

    You can use the following commands to check the DNS resolution issues on the service interface and routes to the surface interface.

    • To check the reachability of a server IP address using ICMP:
    /sc/bin/smmgr -ys smnet='ping <IP address or Domain Name>'
    • To print the server interface IP config details:
    /sc/bin/smmgr -ys smnet=ifconfig
    • To check the DNS resolution of a hostname:
    /sc/bin/smmgr -ys smnet='route'/sc/bin/smmgr -ys host="<Domain Name>" -ys connect=dns
    • To check the communication or port reachability of a server:
    /sc/bin/smmgr -ys host="<FQDN of SIEM server>" -ys port=<Listening port> -ys connect=tcp

    What happens if the NSS goes down?

    In the event of a connection loss between the NSS server and the cloud Nanolog, the cloud retransmits the logs to the NSS up to a maximum of one hour. If the NSS is down for more than an hour, the logs falling out of the one-hour window aren't retrieved by the NSS.

     

    Close

  • This article describes additional features that facilitate deploying the NSS in cases where you have specific requirements or restrictions. It includes the following topics:

    The first three sections listed pertain to the NSS deployment over VMware vSphere only.

    • Sometimes, the default management interface can't be used for SSH due to VLAN restrictions. In those cases, Zscaler recommends that you add an additional interface just for management, so the first interface is used only for control connections to the cloud.

      There are two ways to add a second management interface:

      • Zscaler recommends that you log in to your client and configure the additional interface from the console tab. See Configuring the Additional Interfaces from the Console.

      • To manually add a management interface:

        1. Shut down the NSS and stop the VM.
        2. Using your client, assign an additional interface to the VM. Map it to an appropriate network or VLAN.
        3. Reboot the NSS.
        4. Run the following command and ensure that the em2 interface is active:
        ifconfig
        1. Update the system configuration file /etc/rc.conf to configure the interface automatically after each system restart. To do this, run the following command:
        sudo vi /etc/rc.conf
        1. Add the em2 interface to the list of network interfaces. Modify the line that starts with network_interfaces and change it to:
        network_interfaces="em0 em1 em2 lo0"
        1. Add a new line at the end of the file:
        ifconfig_em2="<subnet-ip-address>"

        Ensure that you replace <subnet-ip-address> with the IP address of the subnet. For example:

        ifconfig_em2="192.168.1.100/24”
        1. The default gateway is automatically added via the em0 interface. To add a static route to a different subnet or VLAN for the newly added em2 interface, add the following lines at the end of the file:
        static_routes="em2"
route_em2="-net <destination-subnet> <gateway-ip-address>"

        Replace <destination-subnet> with the IP address of the destination subnet, and replace <gateway-ip-address> with the appropriate gateway IP address. For example:

        static_routes="em2"
route_em2="-net 198.51.100.0/24 192.168.1.3"
        1. Reboot the VM.
        2. To verify the changes, ping the newly added subnet gateway and run the following command to print the route information:
        sudo netstat -rn
        Close
      Close

    • The NSS typically uses the service interface to download logs from the Nanolog in the Zscaler cloud and send them to the security information and event management (SIEM) system.

      Some organizations might need to use one interface to connect to the Zscaler cloud and another interface to connect to the SIEM. For example, an organization might have a SIEM in a management LAN that is not routed to the internet, and it might also have a service LAN that is routed to the internet but not to the management LAN, as shown in the following diagram.

      Diagram of one interface connecting to the Zscaler cloud and another interface connecting to the SIEM.

      If your organization has a similar requirement, you can configure a second service interface. You can then use one interface to connect to the Zscaler cloud to download the logs and a different interface to send the logs to the SIEM located in the management LAN.

      There are two ways to add a second service interface:

      • Zscaler recommends that you log in to your client and configure the additional interface from the console tab. See Configuring the Additional Interfaces from the Console.

      • To manually add a second service interface:

        1. Shut down the NSS and stop the VM.
        2. Using your client, assign an additional interface to the VM. Map it to an appropriate network or VLAN.
        3. Reboot the NSS.
        4. Run the following command and ensure that the em2 interface is active:
        ifconfig
        1. Copy the sc.conf file.
        cp /sc/conf/sc.conf /sc/conf/sc.conf.old
        1. Use the vi Editor to edit the sc.conf file. Run the following command:
        vi /sc/conf/sc.conf
        1. Add the following lines to the file, replacing the sample values in red per your configuration:
        smnet_dev=em2=zs1:192.168.223.41/24
smnet_route=10.0.0.0/8/192.168.223.1

        In this example, em2=zs1 is the second service interface and 192.168.223.41/24 is the service IP address with the subnet mask. If your SIEM is in the same subnet, then the second line is not required. If your SIEM is in a different subnet, add smnet_route and define values in the second line. For example, to reach 10.0.0.0/8, use gateway 192.168.223.1.

        1. Save the changes in the file and then restart the NSS by running the following command:
        sudo nss restart
        1. Verify if the NSS is using the second service interface by running the following command:
        sudo nss dump-config
        Close
      Close

    • To configure a second management interface and service interface, first ensure that you run the following command to set your network settings:

      sudo nss configure

      Then, run the following command to specify the IP addresses for the additional interfaces and their corresponding routes:

      sudo nss configure split-interface

      Screenshot of FreeBSD command prompt showing the command sudo nss configure split-interface

      During a split-interface configuration, the NSS asks for an smnet_route. If your SIEM is in a different network compared to the NSS smnet interface (em3=zs1) subnet, you can enter specific routes for feeds.

      See the following example:

      [root@NSS /sc/update]# nss configure split-interface
            ifconfig_em2 (Internal Management interface IP address with netmask) [1.1.1.1/23]:
            route_net:-net 1.1.1.2/12 2.1.1.1 (Options <c:change, d:delete, n:no change>) [n]
            Do you wish to add a new route_net? <n:no y:yes> [n]:
            smnet_dev=em3 (Internal Service interface IP address with netmask) [10.10.35.20/24]:
            Do you wish to add a new smnet_route? <n:no y:yes> [n]: y
            Atleast one entry required for smnet_route
            smnet_route (Static route for Siem N/w ,e.g (network/subnet/gateway): 172.12.1.0/21/10.10.35.1) []: 1.3.2.1/2/2.2.1.2
            Do you wish to add a new smnet_route? <n:no y:yes> [n]: 2.1.2.3/2/43.3.3.2
      Close

    • If you have a local NTP Server, you can configure the NSS to synchronize time with that server:

      1. Run the following as root:
      crontab -e
      1. Add the following command:
      PATH=/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/games:/sc/update:/home/zsroot/bin:/sc/update
      1. Add the following command:
      */10 * * * * ntpdate <ntp-server-name>

      Replace <ntp-server-name> with your local NTP server's FQDN or IP address.

      1. Save and exit.

      The time synchronization command runs every 10 minutes. You can find logs for the NTP process in /var/log/cron.

      Close

    • Some customers might have a no default route environment. This prevents the NSS from establishing connections to the Zscaler cloud. For this scenario, you can configure the NSS in explicit proxy mode, so that it tunnels all Zscaler cloud-bound connections through a proxy. These include network connections and TCP connections from the NSS to the:

      • Nanolog (SMSM)
      • Zscaler Central Authority (CA) (SMCA)
      • Update server (SMCDSS) for software updates
      • Kafka server for audit log streaming

      Connections from the NSS to the SIEM are not tunneled.

      The NSS in explicit proxy mode can tunnel Zscaler cloud-bound connections. Based on your configuration, you can tunnel these connections without the need for internet-facing DNS resolution.

      If you configure the dnsoverproxy flag to 1, then the NSS in explicit proxy mode makes a CONNECT request to the following domains and the explicit proxy performs the name resolution:

      • msmca.<cloudname> for the connection to the Zscaler CA
      • zdistribute.<cloudname> for the connection to the update server
      • kproxy.hdeu1.zdataservices.net for the connection to the Kafka server

      If you configure the dnsoverproxy flag to 0, then the NSS needs DNS resolution for the connections to the current master CA IP address, update server, and Kafka server.

      NTP connections are not tunneled. The NSS needs DNS resolution for the NTP server. To learn more, see Configuring a Local NTP Server.

      To configure the NSS in explicit proxy mode:

      1. Run the nss configure command to configure the two network interfaces.
      2. Run the nss configure proxy command. For example:
      [root@NSS /usr/home/zsroot]# nss configure proxy
        proxyserver (Proxy Host ) [10.81.153.26]:
        proxyport (Proxy Port ) [443]:
        dnsoverproxy (DNS over proxy: 0/1 ) []: 1
        Successfully configured proxy

      To undo this configuration, you can use remove:

      nss configure proxy remove

      1. Run the sudo nss restart command to restart the NSS service.

        When the NSS starts, it tries to connect to the Zscaler CA or Nanolog using the proxy it configured.

      2. Run the nss troubleshoot netstat command to verify the proxy (e.g., 10.81.153.26) connections for the Zscaler CA and Nanolog.

      Close

      1. Log in to your NSS VM.
      2. Edit the file /etc/rc.conf using the vi Editor.
      [zsroot@New_Hostname ~/$ vi /etc/rc.conf
      1. Add the hostname entry to the file.
      hostname=<name>
      1. Run the reboot command.
      root@New_Hostname:/usr/home/zsroot # reboot
      1. After the NSS restarts, your new hostname appears.

    • You can restrict SSH access based on IP/Subject using the following configuration in sshd_config:

      AllowUsers zsroot@10.66.70.*

      In this example, SSH is allowed only from the source IP range 10.66.70.0/24. Then, run the following command to make the configuration change effective:

      service sshd restart
      Close

      1. Create a .ssh directory in the home directory: /home/zsroot/ under the user root.
      2. Upload your user public key file to the file authorized_keys under the directory /home/zsroot/.ssh.
      3. Adjust the file /etc/ssh/sshd_config with the following updates. Make a backup of this file before changing it.
      ChallengeResponseAuthentication no
PasswordAuthentication no

      These entries are set to yes by default. You can set them to no or comment them out.

      1. Use the following command to restart the sshd service:
      service sshd restart

      Replace option restart with stop and start as required.

      1. Test the new configuration on the client side using SSH (e.g., PuTTY).
      Close

    Close

  • An NSS server represents the NSS virtual machine (VM) in the ZIA Admin Portal. When you create an NSS server in the portal, an SSL certificate is generated. You download the SSL certificate from the portal and upload it to the NSS VM that you configure and deploy. The newly configured NSS VM uses the SSL certificate to authenticate itself to the Zscaler service.

    Each NSS server supports up to 16 NSS feeds. (Web and Firewall logs are each limited to 8 feeds per NSS to ensure optimal performance.) Each NSS feed can have different filters and fields and a different output format (e.g., CSV).

    For site reliability, you can deploy multiple NSS VMs, either in an active-active or active-passive configuration.

    Active-Active Configuration

    Zscaler recommends leveraging two NSS servers per NSS type (i.e., NSS for Web and NSS for Firewall) and deploying each pair in an active-active configuration. In this configuration, you create two NSS servers of the same NSS type in the ZIA Admin Portal with separate SSL certificates.

    Running multiple active NSS VMs with the same SSL certificate causes cloud connection flapping, which disrupts the streaming of logs to the NSS.

    Optionally, for optimal reliability, you can configure the NSS VMs to stream logs to two separate SIEMs. In this configuration, each NSS VM runs independently, streaming logs to its respective SIEM at the same time.

    Zscaler does not recommend configuring two NSS VMs of the same NSS type to stream logs to a single SIEM. In this case, each NSS VM sends copies of the same logs to the SIEM, which might not be able to deduplicate them.

    Active-Passive Configuration

    Alternatively, you can deploy multiple NSS VMs in an active-passive configuration. In this configuration, you create one NSS server (for Web or Firewall) in the ZIA Admin Portal and use the generated SSL certificate to deploy one active NSS VM; the second VM serves as a cold standby. Both NSS VMs use the same SSL certificate in this configuration, but they should not connect to the Zscaler Nanolog at the same time as this results in connection flapping.

    If the active NSS VM fails, you must perform failover activities, ideally within one hour of the failure to prevent data loss. In this time frame, you can leverage the following NSS reliability mechanisms:

    • NSS to SIEM: The NSS buffers the logs in the VM memory to increase its resiliency to transient network issues between the SIEM and the NSS. If the connection drops, the NSS replays logs from the buffer, according to the Duplicate Logs setting.
    • Nanolog to SIEM: If the connectivity between the Zscaler cloud and the NSS is interrupted, the NSS misses logs that arrived at the Nanolog cluster during the interruption, and they are not delivered to the SIEM. When the connection is restored, the NSS one-hour recovery allows the Nanolog to replay logs up to one hour back.

    To learn more about NSS for Web, NSS for Firewall, and NSS Log Recovery subscriptions, contact Zscaler Support.

    Close
Related Articles
Deploying NSS Virtual AppliancesNSS Deployment Guide for Amazon Web ServicesNSS Deployment Guide for Google Cloud PlatformNSS Deployment Guide for Microsoft AzureNSS Deployment Guide for VMware vSphereNSS Collector Deployment Guide for VMware vSphereConfiguring Advanced NSS SettingsTroubleshooting Deployed NSS Servers