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 intertwined with data from Engage campaigns, 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, with 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.

Avoiding firewalls blocking redirected traffic from remote Collectors

To distinguish traffic from different Collectors, the redirection rule described above keeps the original IP address of the device that sent the Collector packet. However, when redirecting traffic from remote devices, keeping the original IP address of devices may not be possible.

In a setup for redirecting the Collector traffic of remote devices, the redirection Appliance is placed in a DMZ and the firewall between the DMZ and the corporate intranet usually blocks packets coming from the Internet. All redirected packets from remote devices, on which the IP address of the source is left unchanged, are thus typically blocked by the firewall in the DMZ.

To prevent the firewall from blocking remote traffic, include a src parameter in your redirection rules that replaces the original source IP address of devices by the IP address of the redirection Appliance in the DMZ, for example:

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


In this way, traffic from remote devices passes through the DMZ firewall, at the cost of losing original source IP address information.

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. In the forwarding Appliance (Slave Appliance 1 in the figure), type in:

[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 Appliance with IP address 203.0.113.10.

RedirectionTCP.png

In the receiving Appliance (Slave Appliance 2 in the figure):

  1. Enable the receiving port TCP 11301 from the Web Console to prevent the firewall that runs on the Appliance from blocking the redirected traffic.
  2. Add the following lines to the configuration file of nxredirect to send the data from port 11301 in the public interface back to TCP port 11300, where the local Engine is listening:
[listen_grpc='203.0.113.10:11301'
   [send_grpc=localhost:11300]
]

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]

And to anonymize the data controlled by a TCP rule:

[listen_grpc='localhost:11301'
   [anon=encryption_key send_grpc=localhost:11300]
]

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 Local Administrators (groups) Encrypted noUserGroupName
Local Power Users (groups) Encrypted
Windows license key Removed noWindowsKey
Hardware BIOS serial number Removed noBiosSN
Chassis serial number Removed noChassisSN
Device product version Removed noProductSN
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.

Combining anonymization with rule-based assignment of Collectors

Combining anonymized Collector traffic with rule-based Collector assignment is only possible if Collectors are configured to send traffic via TCP only.

For rule-based assignment to work, prevent the anonymization of device fields that are present in the assignment rules. Apply the fine-grained control technique over anonymization described above to any of these fields:

  • Last IP address​
  • Name​
  • Distinguished name reported by Collector​
  • AD site​