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 secondary Appliance (Engine) to other Engines.
Configure the redirection service nxredirect that runs on the secondary 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:
Log in to the CLI of the secondary Appliance.
Open or create the configuration file of the redirection service:
sudo vi /etc/nexthink/nx_redirect.confPress i to insert text.
Write some redirection rules (see below for examples).
Press Esc to stop inserting data.
Save your changes and exit:
:wqRestart the service:
sudo systemctl restart nxredirectFor 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 secondary Appliance to another, enable the additional TCP or UDP ports used for redirection from the Web Console of the secondary 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 secondary 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:
Log in to the CLI of the Engine.
Stop the Engine:
sudo systemctl stop nxengine@1
3. Permanently disable the Engine service:
sudo systemctl disable nxengine@1
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:
The first line tells the nxredirect service to listen to the traffic received by all interfaces on UDP port 999.
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:
In this way, traffic from remote devices passes through the DMZ firewall, at the cost of losing original source IP address information. Starting from V6.24, however, the Collector additionally reports the local IP of the device, which is more reliable than the source IP address. Indeed, the source IP address of a device can be manipulated in transit by any router doing network address translation (NAT) before reaching the target Engine.
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:
Log in to the CLI of the secondary Appliance.
To edit the configuration file of nxproxy, type in:
sudo vi /var/nexthink/nxproxy/conf/nxproxy.confPress i to insert text.
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"Press Esc to stop inserting data.
To save your changes and exit, type in:
:wqBack 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 (secondary Appliance 1 in the figure), type in:
The first line tells the nxredirect service to listen to the traffic received locally from nxproxy on TCP port 11301.
The second line sends the received Collector packets to the local Engine.
The third line sends the received Collector packets to TCP port 11301 of the secondary Appliance with IP address 203.0.113.10.
In the receiving Appliance (Slave Appliance 2 in the figure):
Enable the receiving port TCP 11301 from the Web Console
to prevent the firewall that runs on the Appliance from blocking the redirected traffic.
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:
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:
And to anonymize the data controlled by a TCP rule:
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
RELATED TASKS
RELATED REFERENCES
Last updated
