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

NSS Deployment Guide for Amazon Web Services

Zscaler's Nanolog Streaming Service (NSS) can be deployed via Amazon Web Services (AWS). This guide describes the tasks required for NSS deployment, enabling you to stream either web logs or Firewall logs to a security information and event management (SIEM) system.

As shown in the following diagram, the web and mobile traffic logs and the Firewall logs are stored in the Nanolog in the Zscaler cloud. An organization can deploy the NSS instance either on-premises on an ESX Virtual Machine (VM) or on an EC2 Instance on AWS. When an organization deploys one NSS for web and mobile logs and another NSS for Firewall logs, each NSS opens a secure tunnel to the Nanolog in the Zscaler cloud. The Nanolog then streams copies of the logs to each NSS in a highly compressed format to reduce bandwidth footprint; the original logs are retained on the Nanolog.

Diagram of copies of web and mobile logs and firewall logs being streamed to each NSS in a compressed format through AWS

Prerequisites

Contact Zscaler Support to request the NSS Amazon Machine Image (AMI) to be shared. Provide your AWS account ID and AWS region in which you want the AMI. After deployment, the NSS VM receives automatic software updates from the Zscaler cloud.

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

  • Use this step in this guide to get your recommended instance specifications.

    • EC2 instance type: One of the following dual-core instances. NSS uses one core for the control plane and another core for the data plane:
      • m4.large
      • r4.large
      • r4.xlarge
      • r4.4xlarge
    • Instance memory:
      • 8 GB for up to 15K users
      • 16 GB for up to 40K users
      • 32 GB for up to 100K users
    • EBS storage volume type: Magnetic is sufficient, but General Purpose SSD is recommended.
    • Data disk size: 500 GB
    Close

    • Two network interfaces:

      • 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.

      Second management or service network interfaces are currently not supported in the NSS over AWS deployment.

    • Two Elastic IPs to assign a public IP address with both network interfaces. The two elastic IPs 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 instance behind a VM 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, refer to the Zscaler Cloud 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 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 IP 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:

  • Before you set up an NSS server on the ZIA Admin Portal, you are required to enter information about your traffic and users so that the Zscaler service can compute the appropriate resources for your NSS. The NSS buffer logs for at least one hour. If a SIEM goes offline for maintenance, or if the connection between the NSS and the SIEM is disrupted, NSS buffers the logs and sends them after the connection is re-established. The amount of memory required to buffer the logs is incorporated into the VM spec computation. The buffer size increases proportionally to the amount of RAM allocated to NSS.

    To add an NSS server:

    1. Go to Administration > Nanolog Streaming Service.
    2. From the NSS Servers tab, click Add NSS Server.

    The Add NSS Server window appears.

    1. In the Add NSS Server window:
      • Name: Enter a name for the NSS.

      • Type: The NSS for Web type is selected by default. To configure NSS 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 is Enabled by default.

    1. Click Save.
    2. Click Download in the SSL Certificate column of the NSS that you are configuring, and then save the certificate for uploading to AWS.

    Close

  • Use the following procedure to launch a new EC2 instance with an NSS AMI, configure two network interfaces with Elastic IPs, and configure the required security group settings:

    1. In the top-right corner of the screen, select the region where you want to launch the instance.

    1. Create a new security group:
      1. Go to the Amazon EC2 console.
      2. On the side menu, go to Network & Security > Security Groups.
      3. Click the Create Security Group button, and configure the following:
        • Security Group Name: Name the group Zscaler NSS. You associate this security group with the two network interfaces that you create in the EC2 Instance Provisioning Wizard.
        • Description: The required description cannot be longer than 255 characters.
        • VPC: The VPC of the security group

    1. On the Inbound tab, click the Add Rule button, and configure the connection requirements.

    To connect to your EC2 instance via SSH, you're required to open port 22 for inbound connections. In production, you should authorize only a specific IP address or range of addresses to access your instance and not use 0.0.0.0. To learn more, see Authorizing Inbound Traffic for Your Linux Instances.

    1. On the Outbound tab, click the Add Rule button, and configure the connection requirements.

    1. Click Create.

    The inbound and outbound rules are required to enable the NSS AMI to communicate with the Zscaler cloud and Nanolog and enable remote control of the instance via SSH. You can find more details about the outbound connection requirements on https://config.zscaler.com/<Zscaler Cloud Name>/nss. The <Zscaler Cloud Name> can be found in the URL that you use to log in to the ZIA Admin Portal. For example, if you log in to admin.zscaler.net, then go to https://config.zscaler.com/zscaler.net/nss.

    1. Launch and complete a new EC2 instance:
      1. Go to the Amazon EC2 console.
      2. Under Create Instance, click the Launch Instance button.
      3. On the side menu, click the My AMIs tab.
      4. On the side menu, under Ownership, check the box Shared with me.
      5. Locate the latest AMI shared with your account, and click the Select button.

    To be able to see the NSS AMI on your AMI tab, you need to provide Zscaler with your AWS Account ID and region. Zscaler privately shares the AMI with you.

    1. Choose the EC2 instance type recommended in the ZIA Admin Portal.

    Zscaler’s EC2 instance type recommendation is based on the expected number of transactions, users, and the most economical option for the customer. If you are unable to select the recommended type, contact Zscaler Support for further guidance.

    1. Click Next: Configure Instance Details.
    2. On the Subnet drop-down menu, select the subnet of the instance.

    1. Under Network Interfaces, click the Add Device button to add an additional network interface. Ensure to select the same subnet.

    By default, the EC2 instance has one network interface (eth0), but NSS requires an additional interface (eth1) in the same subnet. The management interface (eth0) is used for control connections to the Zscaler cloud and to make an SSH connection to the NSS for configuration and management. The service interface (eth1) is used for data connections to the Zscaler cloud (streaming nanologs) and to the SIEM (syslog feed).

    1. Click Next: Add Storage.
    2. Choose the recommended specifications given in the ZIA Admin Portal.

    General Purpose SSD is recommended as the volume type, but Magnetic is sufficient.

    1. Click Next: Add Tags, and add any necessary tags.
    2. Click Next: Configure Security Group.
    3. Click Select an existing security group, and choose the security group that you created earlier, Zscaler NSS. Under Source, change 0.0.0.0 to a specific IP address from which you want to enable access.

    1. Click Review and Launch to review your information.
    2. Click Launch, and select a key pair.

    1. Click Launch Instances. The Launch Status page tells you if the launch is successful.

    1. Create and associate two Elastic IPs:
      1. Go to the Amazon EC2 console.
      2. On the side menu, go to Network & Security > Network Interfaces.
      3. Note the network interface IDs of the network interfaces that you created previously. You need one of the IDs when associating an Elastic IP to the network interfaces.

    1. Go to Network & Security > Elastic IPs.
    2. Click the Allocate new address button to allocate a new Elastic IP address.
    3. Click Allocate. Repeat this step and the preceding step to have two Elastic IP addresses.

    1. Right-click on one of the Elastic IPs, and click Associate Address.
    2. On the Associate Address page, configure the following:
      • Resource Type: Select the Network Interface option.
      • Network interface: Choose one of the network interface IDs that you noted earlier.

    You can choose to either complete the Network Interface section or the Private IP section.

    1. Click Associate.
    Close

  • The following NSS configuration steps run through an SSH terminal connection. The connection must use basic authentication. Use zsroot/zsroot when prompted for credentials.

    Zscaler recommends changing the default password.

    Before you start:

    1. Ensure you have completed this step in the guide.
    2. Note the private IP address and subnet mask of the service network interface (eth1) that you created in AWS:
      1. In AWS, go to EC2.
      2. In the left-side navigation, go to Instances.

      3. Select the service network interface (eth1) that you created, and then click the Networking tab.

      4. In the Network Interfaces section, copy the Private IPv4 address (e.g., 10.0.1.196) and save for later use.

      5. In the Networking details section, click the Subnet ID link.

        The Subnets page appears.

      6. On the Subnets page, select the subnet and note the subnet mask (e.g., /24) in the IPv4 CIDR column.

    Configuring the NSS Virtual Appliance on AWS

    To configure the NSS virtual appliance on the VM:

      1. Copy the downloaded file from the ZIA Admin Portal to the VM, using FTP, SCP, or SFTP.
      2. Find the public hostname or IP address of your instance in the VM.
      Close
      1. Use an SSH command such as follows to get shell access to the VM:
      ssh zsroot@Public-Host-Name
      1. Use the following username/password: zsroot/zsroot.
      Close

    • NSS uses an SSL certificate to authenticate itself to the Zscaler service. Make sure that the SSL certificate is installed on only one active NSS VM at a time. Having multiple NSS VMs that use only one certificate causes cloud connection flapping, which disrupts the streaming of logs to the NSS.

      1. Copy the NssCertificate.zip file to the /home/zsroot root directory.
      2. Run the following command:
      sudo nss install-cert NssCertificate.zip
      1. Check the configuration by running the following command:
      sudo nss dump-config
      Close

      1. Enter the command netstat -rn and note the default gateway IP address. For example:

        DestinationGateway
        Default172.31.16.1
        127.0.0.1link#1
        172.31.16.0/20link#3
        172.31.30.202link#3

      The first network interface (management network) is configured by default when you start the VM.

      1. Configure the NSS network (service interface only). You are then prompted for several IP configurations.
      2. Enter the command sudo nss configure and complete the following:
        1. Enter a name server (e.g., 172.31.0.2). You can either change (C), delete (D), or not change it (N). In this case, enter N.
        2. You can add a name server if you want. In this case, enter N.
        3. Enter the service interface IP address with the subnet mask (smnet_dev). This is the private IP address and subnet mask of the second network interface (service interface - eth1) created in the VM. You noted these values (e.g., 10.0.1.196/24) in a previous step.
        4. Enter the service interface default gateway IP address (smnet_dflt_gw). This is the default gateway IP address (e.g., 172.31.16.1). You can find it by running the command netstat -rn.
      Close

    • 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.

      Close

    • Unless you are planning to use this instance for passive backup, run the command sudo nss start and ensure that the command shows that the NSS virtual appliance started successfully. It can take a few minutes for the NSS to start streaming logs to the SIEM.

      After starting the NSS for the first time, you can run the following command to check that the latest NSS software version is installed:

      sudo nss checkversion

      To enable the NSS to start automatically after a restart, run the following command:

      sudo nss enable-autostart

      You can also explore other options by running the following command:

      sudo nss help
      Close

    • To verify the configuration, run the following command:

      sudo nss troubleshoot netstat|grep tcp

      When the output of the command is displayed, verify that the following TCP connections are established in the following order:

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

      The absence of any one of the preceding connections, even after waiting a few minutes, usually indicates that there is a firewall configuration issue and the logs cannot be streamed. To troubleshoot issues, see Troubleshooting Deployed NSS Servers.

      Close
    Close

  • An NSS feed specifies the data from the logs that the NSS sends to the SIEM. You can filter the data, so that you send only the data that 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 16 NSS feeds for each NSS. (Web and Firewall logs are each limited to 8 feeds per NSS to ensure optimal performance.) Each feed can have a different list of fields, a different format, and different filters. To learn more, see Adding NSS Feeds.

    Close

Post-Deployment Tasks

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

  • 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

  • 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

    • To update your NSS VM hostname:

      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

    • To set up key-based authentication to the NSS on ESX:

      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

  • 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
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