Redirecting Collector traffic

Contents

Redirecting Collector traffic

Overview

To deal with remote devices, add redundancy or anonymize information on the fly, redirect the Collector traffic that reaches one Engine to other Engines.

Configure the redirection service nxredirect that runs on the Engine appliance to forward the UDP traffic received from the Collectors to other Engines of your choice.

The redirection service can handle the traffic of 5 to 350 thousand devices depending on the available hardware and setup.

To forward the TCP connection between the Collector and the Engine required for the automatic update of the Collector, acting on the devices of the end users, or engaging with the end users, read the article about TCP redirection.

Configuring the redirection service

For the redirection service to automatically start after every system boot:

  1. Log in to CLI of the Engine.
  2. Enable the redirection service:
    sudo systemctl enable nxredirect

To configure the redirection service:

  1. Log in to the CLI of the Engine.
  2. Open or create the configuration file of the redirection service:
    sudo vi /etc/nexthink/nx_redirect.conf
  3. Write some redirection rules (see below for examples).
  4. Save your changes and exit:
    :wq
  5. Restart the service:
    sudo systemctl restart nxredirect

Stopping the Engine service

To use the Engine appliance exclusively for redirection, stop the Engine service and disable it so it does not restart on every reboot of the appliance:

  1. Log in to the CLI of the Engine.
  2. Stop the Engine:
    sudo systemctl stop [email protected]
  3. Permanently disable the Engine service:
    sudo systemctl disable [email protected]

Disabling the Engine removes the memory and CPU consumption of the Engine process from the redirecting appliance.

Writing redirection rules

The following lines are a sample configuration of the redirection service:

listenraw port=999
[dst=192.168.0.25:997,192.168.0.26:997 send]


  1. The first line tells the nxredirect service to listen to the traffic received by all interfaces on port 999.
  2. The second line sends the received Collector packets to port 997 of the Engines with IP addresses 192.168.0.25 and 192.168.0.26.

Anonymizing redirected traffic

For generic data analysis purposes, you may want to have access to all the data in an Engine related to services, connections, executions, etc. without necessarily associating them to a particular person or group of people. That is, you may want to analyze the data collected while keeping users, devices, and printers anonymous.

To have a redundant Engine that holds all significant data while hiding sensitive information about users, devices, and printers, redirect traffic to that Engine with anonymization turned on. To anonymize Collector traffic, configure the redirection service as in the following example:

listenraw port=999
[anon=encryption_key dst=192.168.0.27:998 send]


Note the addition of the anon keyword, followed by the encryption key of your choice. For the sake of efficiency, use it preferably before specifying the destinations, specially if you have many. In that way, anonymization takes place only once before replicating and splitting the traffic.

When anonymizing Collector traffic, some fields of the device, the user, and the printer objects are encrypted, other fields are randomized, and others are removed.

Fine-grained control over anonymization

By default, anonymization takes an all-or-nothing approach. When anonymization is turned on, the values of all the fields listed in the tables below are actually modified.

In some situations, however, you may be interested in preserving the original values of some of those fields. To exclude a particular field or set of fields from being anonymized, add a list of comma separated exceptions to the anon rule in the configuration of the redirection service. For example, to anonymize neither the names of users nor the names of devices:

[anon=key,noUserName,noDeviceName dst=192.168.0.27:998 send]

For each anonymizable field, find the keyword to turn off its anonymization under the Exception column of the tables below.

Device anonymization

Device Field Action Exception
Properties SID Randomized noDeviceSId
Name Encrypted noDeviceName
AD Site Removed noDeviceDS
Distinguished name reported by Collector Removed noDeviceDN
Network Last IP address Replaced by Engine IP noDeviceIP
IP addresses Replaced by Engine IP noDeviceIP
MAC Randomized noDeviceMacs
Group name Encrypted noDeviceGroupName
Operating system Windows license key Removed noWindowsKey
Hardware BIOS serial number Removed noBiosSN
Chassis serial number Removed noChassisSN
Device UUID Removed noUuidSN
Active Directory Distinguished name Not retrieved -

Note that a change in the encryption key implies a duplication of the devices. If you are redirecting to an existing Engine, remember to erase the database to avoid duplications.

User anonymization

User Field Action Exception
Properties SID Randomized noUserSId
Name Encrypted noUserName
Active Directory Distinguished name Not retrieved -
Full name Not retrieved -
Department Not retrieved -
Job title Not retrieved -

Printer anonymization

Printer Field Action Exception
Properties Name Encrypted noPrinterName

Print Job anonymization

Print Job Field Action Exception
Properties Document name Removed noPrintJobDocName
User User name Removed noPrintJobUserName

Note that the document name of a Print Job is not stored in the Engine and, therefore, not visible in the Finder. Nevertheless, the Collector sends the document name through the network and it is stored when Collector traffic is captured. Hence the possibility to anonymize it.