Redirecting and anonymizing Collector traffic

Contents

Redirecting and anonymizing Collector traffic

Overview

To forward Collector traffic from remote devices, duplicate traffic for redundancy purposes, or anonymize end-user data on the fly, redirect the Collector traffic from the slave Appliance (Engine) to other Engines.

Configure the redirection service nxredirect that runs on the slave Appliance to forward (and optionally anonymize) the traffic received from the Collectors to other Engines of your choice.

While the Collector traditionally sends end-user data to the Engine through its UDP channel, starting from V6.21, the Collector may alternatively send end-user data through its TCP channel. The redirection service has been therefore adapted to handle end-user data received via either the UDP or the TCP channels. When sent through the TCP channel though, end-user data is interwined with data from Engage campaings, Act remote actions, and software updates. Because the redirection service processes end-user data only, the nxproxy component on the Engine Appliance must first receive all the TCP data and split them between end-user data, which will feed the redirection service, and data from Engage, Act, or updates.

To redirect the full TCP channel, wiht or without optional end-user data, read the article about TCP redirection.

Configuring the redirection service

To configure the redirection service:

  1. Log in to the CLI of the slave Appliance.
  2. Open or create the configuration file of the redirection service:
    sudo vi /etc/nexthink/nx_redirect.conf
  3. Press i to insert text.
  4. Write some redirection rules (see below for examples).
  5. Press Esc to stop inserting data.
  6. Save your changes and exit:
    :wq
  7. Restart the service:
    sudo systemctl restart nxredirect
  8. For the redirection service to automatically start after every system boot:
    sudo systemctl enable nxredirect

Depending on the redirection service receiving TCP or UDP data, the rules to control the redirection have a different syntax. Note however that you can combine the two types of rules if the redirecting Appliance receives Collector data from both channels. The difference in the syntax of the rules and other possible differences in the configuration of the Appliance are detailed below.

Enabling communication through the redirected ports

When redirecting traffic to other (non local) Appliances, the redirection ports are usually not the standard ports of the Appliance, as listed in the connectivity requirements. Therefore, the hardening of the Appliance blocks the communication through the redirected ports by default.

To allow the redirection of Collector traffic from one slave Appliance to another, enable the additional TCP or UDP ports used for redirection from the Web Console of the slave Appliance that receives the redirected traffic.

Redirection of end-user data via UDP

To obtain the maximum performance out of the redirection service, if all the Collectors in a setup send end-user data through the UDP channel, redirect Collector traffic by means of a slave Appliance where the Engine is preferably stopped.

The redirection service can handle the UDP traffic from 5 000 up to 350 000 devices, depending on the available hardware and setup, as anonymization and a running Engine have an impact on the performance.

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 for the UDP channel

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

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

Redirection of end-user data via TCP

If all or some of the Collectors in a setup send their data through the TCP channel only, configure the nxproxy component to split the TCP data between Engage, Act, or updates data, which is directly sent to the Engine that runs on the same Appliance, and end-user data, which is sent to the redirection service.

Configuring Nxproxy

To configure nxproxy to split the TCP channel and send end-user data to the redirection service:

  1. Log in to the CLI of the slave Appliance.
  2. To edit the configuration file of nxproxy, type in:
    sudo vi /var/nexthink/nxproxy/conf/nxproxy.conf
  3. Press i to insert text.
  4. To redirect end-user data to port 11301, instead of the default port 11300 (to which the Engine listens), type in:
    nxproxy.tcp-collector.engine.grpc.address="localhost:11301
  5. Press Esc to stop inserting data.
  6. To save your changes and exit, type in:
    :wq
  7. Back to the CLI, restart nxproxy by typing in:
    sudo systemctl restart nxproxy

Writing redirection rules for the TCP channel

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

[listen_grpc='localhost:11301'
[send_grpc=localhost:11300]
[send_grpc=203.0.113.10:11301]
]


  1. The first line tells the nxredirect service to listen to the traffic received locally from nxproxy on TCP port 11301.
  2. The second line sends the received Collector packets to the local Engine.
  3. The third line sends the received Collector packets to TCP port 11301 of the slave Appliances with IP address 203.0.113.10.

RedirectionTCP.png

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, precede the redirection rule (be it a TCP or a UDP redirection rule) by the anon keyword and specify the encryption key of your choice. For instance, to anonymize the data controlled by an UDP rule:

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


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 in the TCP channel and send the result to the local Engine, type in:

[anon=key,noUserName,noDeviceName send_grpc=localhost:11300]

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.