Configuring Tanium Client peering

Overview of Tanium Client peering settings

Peering settings define the subnet boundaries of the linear chains in which Tanium Clients form peer relationships. Peering settings are designed to optimize the network resources that are required to manage endpoints by ensuring that most data transmission is distributed among the low-latency, high-bandwidth links of local area networks (LANs). Using mostly LAN links dramatically reduces utilization over the wide area network (WAN).

For details about how Tanium Client peering works and related concepts, see Client peering.

In addition to configuring the settings that define subnet boundaries, you can also configure the Tanium Client to periodically select a new listening port at random, instead of using a fixed port, for communications from peers. See Randomize listening ports.

The default client peering settings are useful for optimizing network resources even when you do not have much information about the enterprise network. As a best practice, work with your network administrators and Tanium Support to configure a few key settings that further optimize peer communication based on the details of your particular network (see Contact Tanium Support). For example, separate settings apply to clients that connect directly to the Tanium Server than to clients that connect to a Tanium Zone Server. Focus on the following objectives when tuning the settings:

  • LAN peering only: The default address mask (IPv4) and address prefix (IPv6) settings are designed to prevent Tanium Client peering across WANs. For details, see Address mask and prefix settings.
  • Separated subnets: Use the separated subnets configuration to specify more granular exceptions to the boundaries that the address mask or prefix settings define. For example, you might have a subnet that crosses WAN links and that is smaller than the subnet boundaries that the AddressMask setting defines. In this case, you can define separated subnets within that smaller subnet so that its clients do not peer across the WAN links. For details, see Configuring Tanium Client peering.
  • Isolated subnets: Use the isolated subnets configuration to specify the addresses of subnets and endpoints for which you want to disable Tanium Client peering. The best practice is to disable peering for virtual private network (VPN) clients and clients that you install on the Tanium Server or Zone Server. You can configure Isolated subnets that are standalone subnets or that comprise smaller linear chains within the chain that the AddressMask or zs_address_mask setting defines (see Figure  1). For details, see Configure isolated subnets.

When Tanium Clients register through the Tanium Server or Zone server, the server evaluates all these peering settings and applies the most restrictive rule with respect to the subnet range. For example, if a client IP address is within both a /24 subnet that the AddressMask defines and a /26 subnet that the separated subnets configuration defines, the server applies the peering boundaries of the separated subnet to that client.

In Tanium Core Platform 7.4.3 or later, Tanium Servers write subnet configurations to the Tanium database and automatically synchronize them in an HA deployment. On Zone Servers, you must manually configure and maintain SeparatedSubnets.txt and IsolatedSubnets.txt files that resides in the Zone Server installation folder.

Tanium Core Platform 7.2 or earlier supports only IPv4. If you need IPv6 support in version 7.3 or later, Contact Tanium Support. Each Tanium Client can register with the Tanium Server as an IPv4 client or IPv6 client, but not both. Also, a Tanium deployment can include both IPv4 and IPv6 linear chains, but each chain contains clients for only one IP version; IPv4 clients can never peer with IPv6 clients.

Figure  1 illustrates an IPv4 deployment where internal Tanium Clients connect with Tanium Servers in a high availability (HA) deployment and external clients connect with the Zone Server.

1 AddressMask and zs_address_mask

When each Tanium Client registers, the Tanium Server or Zone Server sends the client a neighborhood list. This is a list of adjacent clients that are optimal for peering and that are within the boundaries that the AddressMask or zs_address_mask setting defines. In this example, both settings apply the default /24 netmask as the linear chain boundaries.

In Figure  1, the Zone Server uses the zs_address_mask that it receives from a Tanium Server. If necessary, you can override the setting by configuring the AddressMask locally on the Zone Server.

2 Separated subnets configuration

Upon evaluating the separated subnets configuration, the Tanium Servers and Zone Server apply exceptions that define smaller linear chains contained within the AddressMask or zs_address_mask chains. Because the Tanium Servers read the separated subnets configuration on the Tanium database, the configuration is synchronized between the HA servers. The Zone Server reads the configuration from the SeparatedSubnets.txt file that resides in the Zone Server installation folder.

3 Isolated subnets configuration

The Tanium Servers and Zone Server evaluate the isolated subnets configuration to define linear chains for subnets in which the clients do not peer with each other. Because the Tanium Servers read the isolated subnets configuration on the Tanium database, the configuration is synchronized between the HA servers. The Zone Server reads the configuration from the IsolatedSubnets.txt file that resides in the Zone Server installation folder.

Figure  1:  Tanium Client peering

Address mask and prefix settings

Contact Tanium Support if you need to modify the following Tanium Client peering settings.

AddressMask

In IPv4 subnets of Tanium Clients that register with the Tanium Server, AddressMask governs the network proximity of client peers to prevent suboptimal peer connections (such as connections across WANs). The Tanium Server installation automatically adds the setting (Administration > Management > Local Settings) with a default value that limits peering to neighbors that share the same 24-bit address mask. For example, a Tanium Client in subnet 192.168.0.0/24 can peer with other Tanium Clients in 192.168.0.0/24 but not those in 192.168.1.0/24. When each Tanium Client registers with the Tanium Server, the server sends the client a list of neighbors with which it can attempt to peer. This neighborhood list adheres to the AddressMask boundary.

zs_address_mask

In IPv4 subnets of Tanium Clients that register with the Zone Server, zs_address_mask governs the network proximity of client peers to prevent suboptimal peer connections. The Zone Server receives the setting from the Tanium Server (Administration > Management > Global Settings) with a default value that limits peering to neighbors that share the same 24-bit address mask. If necessary, you can override the global setting by configuring AddressMask locally on each Zone Server. When each Tanium Client registers with the Zone Server, the server sends the client a neighborhood list that adheres to the zs_address_mask (or local AddressMask) boundary.

AddressPrefixIPv6

(Tanium Core Platform 7.3 or later) In IPv6 subnets of Tanium Clients that register with the Tanium Server, AddressPrefixIPv6 governs the network proximity of client peers to prevent suboptimal peer connections. By default, this setting is not visible until you manually configure it (Administration > Management > Local Settings). The default value is 0, which specifies no peering. When each Tanium Client registers with the Tanium Server, the server sends the client a neighborhood list that adheres to the AddressPrefixIPv6 boundary. Contact Tanium Support to determine the optimum value for peering in IPv6 networks.

zs_address_prefix_ipv6

(Tanium Core Platform 7.3 or later) In IPv6 subnets of Tanium Clients that register with the Zone Server, zs_address_prefix_ipv6 governs the network proximity of client peers to prevent suboptimal peer connections. The Zone Server receives the setting from the Tanium Server (Administration > Management > Global Settings). The default value is 0, which specifies no peering. If necessary, you can override the global setting by configuring AddressPrefixIPv6 locally on each Zone Server. When each Tanium Client registers with the Zone Server, the server sends the client a neighborhood list that adheres to the zs_address_prefix_ipv6 (or local AddressPrefixIPv6) boundary. Contact Tanium Support to determine the optimum value for peering in IPv6 networks.

Configure separated subnets

Configure separated subnets to specify more granular exceptions for Tanium Client peering than the subnet boundaries that you set through the address mask or prefix settings (see Address mask and prefix settings). Clients use the separated subnets configuration for peering based on whether they connect to the Tanium Server or Zone Server. Each server uses the configuration to manage the peer lists for clients that register through it.

After you configure separated subnets, you do not have to restart the Tanium Server or Zone Server. Tanium Clients take two to six hours (the randomized client-reset interval) to finish applying all the changes associated with the new configuration.

In most environments, the separated subnets configuration is the same for all Zone Servers and Tanium Servers, and the best practice is to keep the configuration synchronized across servers to avoid confusion. In complex environments with overlapping subnets, you might have to segregate subnets differently for Zone Servers. In such cases, you can modify SeparatedSubnets.txt on each Zone Server that requires a unique configuration.

A user role with the Read Separated Subnets permission is required to view the separated subnets configuration. The Write Separated Subnets permission is required to create, modify, or delete the separated subnets configuration. The Administrator reserved role has these permissions.

Figure  1 shows an example deployment with separated subnets.

Configure separated subnets on the Tanium Server

  1. From the Main menu, go to Administration > Configuration > Subnets.
  2. In the Separated Subnets section, click New Subnets.
  3. Enter each separated subnet in CIDR format (such as: 192.168.2.0/26), with one line per entry. Use the ; or # character before any optional comments.

    Tanium Core Platform 7.3 or later supports IPv6 subnets (for details, contact Tanium Support at [email protected]). You must enter IPv6 subnets within square brackets followed by the prefix (such as: [2001:db8::]/32).

    See the following example:

    192.168.0.0/26 #This is a data center subnet.
    192.168.2.0/26 ;This is a branch office subnet.
    [2001:db8::]/32

    If your deployment includes Zone Servers, copy your entries from the text field to your clipboard to facilitate the associated task: Configure separated subnets on a Zone Server.

  4. Click Save.

Configure separated subnets on a Zone Server

If your deployment includes Zone Servers, perform the following steps based on your Tanium infrastructure to add a separated subnets configuration to each server.

Windows infrastructure

  1. Create a plain text file named SeparatedSubnets.txt.
  2. Copy and paste the separated subnets information that you entered for the Tanium Server into SeparatedSubnets.txt.

    If you did not already copy the information to your clipboard, go to Administration > Configuration > Subnets, select the separated subnets configuration, click Edit, and copy the entries from the text field.

  3. Move SeparatedSubnets.txt to the installation folder of each Zone Server (default is \Program Files (x86)\Tanium\Tanium Zone Server). If necessary, you can modify the file contents for each Zone Server that requires a unique configuration.

Tanium Appliance infrastructure

  1. On the Zone Server appliance, sign into the TanOS console as a user with the tanadmin role.
  2. From the tanadmin menu, enter 2 to go to the Tanium Operations menu. ClosedView screen
  3. Enter 2 to go to the Configuration Settings menu. ClosedView screen
  4. Enter 12 to edit the SeparatedSubnets.txt file. ClosedView screen
  5. Use the menu to specify subnets in CIDR format.

Configure isolated subnets

Configure isolated subnets to disable client peering for a specified list of subnet and endpoint IP addresses. If the IP address of a Tanium Client is in an isolated subnet, the Tanium Server or Zone Server sends that client an empty peer list to prevent the client from participating in peering. Each server uses the configuration to manage the peer list for Tanium Clients that register through it.

If you install the Tanium Client on the Tanium Server or Zone Server host computer (Windows deployment only), it might be appropriate to add the IP address of that host to the isolated subnets configuration. When the Tanium Client is installed on the same host as the server, the client automatically listens for peer traffic on port 17473 instead of 17472. If port 17473 is blocked, you might encounter issues during client peering activities, such as file distribution.

After you configure isolated subnets, you do not have to restart the Tanium Servers or Zone Servers. Tanium Clients take two to six hours (the randomized client-reset interval) to finish applying all the changes associated with the new configuration.

Configure isolated subnets for Tanium Clients that are in VPNs. VPN clients have local IP addresses in a special VPN address block, but their host endpoints are actually not close to each other. VPN clients would use WAN links for peering and latency would be significantly greater than for client-to-server connections.

You might find it convenient to use isolated subnets to disable peering in other cases, such as for testing or debugging peering when you have to troubleshoot network issues. Note that disabling peering causes Tanium Clients to consume more network resources in terms of bandwidth and client-server connections over the WAN. For troubleshooting cases, after you resolve the network issues, the best practice is to remove the clients from the isolated subnets configuration so that they resume peering.

In most environments, the isolated subnets configuration is the same for all Zone Servers and Tanium Servers, and the best practice is to keep the configuration synchronized across servers to avoid confusion. In complex environments with overlapping subnets, you might have to segregate subnets differently for Zone Servers. In such cases, you can modify the subnets configuration on each Zone Server that requires a unique configuration.

A user role with the Read Isolated Subnets permission is required to view the isolated subnets configuration. The Write Isolated Subnets permission is required to create, modify, or delete the isolated subnets configuration. The Administrator reserved role has these permissions.

Figure  1 shows an example deployment with isolated subnets.

Configure isolated subnets on the Tanium Server

  1. From the Main menu, go to Administration > Configuration > Subnets.
  2. In the Isolated Subnets section, click New Subnets.
  3. Enter each isolated subnet in CIDR format (such as 192.168.2.0/26), with one line per entry. Use the ; or # character before any optional comments.

    Tanium Core Platform 7.3 or later supports IPv6 subnets (contact Tanium Support at [email protected]). You must enter IPv6 subnets within square brackets followed by the prefix (such as [2001:db8::]/32).

    See the following example:

    192.168.0.0/26 #This is a data center subnet.
    192.168.2.0/26 ;This is a branch office subnet.
    [2001:db8::]/32

    If your deployment includes Zone Servers, copy your entries from the text field to your clipboard to facilitate the associated task: Configure isolated subnets on a Zone Server.

  4. Click Save.

Configure isolated subnets on a Zone Server

If your deployment includes Zone Servers, perform the following steps based on your Tanium infrastructure to add an isolated subnets configuration to each server.

Windows infrastructure

  1. Create a plain text file named IsolatedSubnets.txt.
  2. Copy and paste the isolated subnets information that you entered for the Tanium Server into IsolatedSubnets.txt.

    If you did not already copy the information to your clipboard, go to Administration > Configuration > Subnets, select the isolated subnets configuration, click Edit, and copy the entries from the text field.

  3. Move IsolatedSubnets.txt to the installation folder of each Zone Server (default is \Program Files (x86)\Tanium\Tanium Zone Server). If necessary, you can modify the file contents for each Zone Server that requires a unique configuration.

Tanium Appliance infrastructure

  1. On the Zone Server appliance, sign into the TanOS console as a user with the tanadmin role.
  2. From the tanadmin menu, enter 2 to go to the Tanium Operations menu. ClosedView screen
  3. Enter 2 to go to the Configuration Settings menu. ClosedView screen
  4. Enter 11 to edit the IsolatedSubnets.txt file. ClosedView screen
  5. Use the menu to specify subnets in CIDR format.

Verify Tanium Client peering and leader connections

To verify changes to the peering settings of Tanium Clients, you can use the Tanium Console or examine Tanium Client configurations on the host endpoints.

Use the Tanium Console

Tanium Clients receive updated peer lists during registration. Go to Administration > Management > Client Status to verify that the status is as expected considering the Last Registration date and time. You can sort the rows by Network Location and browse to review client peering status across subnets.

Figure  2:  Tanium Client peering status

The Status column indicates whether the Tanium Client is a leader (for details on leaders, see Client peering). A blank entry indicates a normal (non-leader) peer. You can use the Status column to track how your configuration changes affect leader count.

The Direction column displays icons to depict Tanium Client connection states. The icons use the following conventions:

  • An up arrow indicates a connection with the Tanium Server or Zone Server.
  • Side arrows pointing away from the client indicate outbound connections to peers.
  • Side arrows pointing at the client indicate inbound connections from peers.
  • Side arrows on the right side of clients indicate the state of connections to forward peers.
  • Side arrows on the left side of clients indicate the state of connections to backward peers.
  • Side arrows with dashed lines indicate slow connections.

You can use the Direction column to understand the reasons that the client is a leader and to identify connection issues. The following table lists the possible connection states:

Table 1:   Tanium Client peer connection states
Attribute Value Description
Leader Backward

Backward leader

The client is a backward leader that terminates one end of a linear chain. It typically has the lowest IP address in its linear chain.
Forward

Forwared leader

The client is a forward leader that terminates one end of a linear chain. It typically has the highest IP address in its linear chain.
Neighborhood

Leader

The client is designated as a neighborhood leader because its linear chain has reached the maximum number of clients.
Isolated

No peering

The client is an isolated leader that connects only to the Tanium Server or Zone Server, and has no connections to other clients. The client might be isolated because its IP address falls within the range of an isolated subnet or because it has no peers in its local subnet with which to connect.
Neighbor No side arrows

No peering

This is the same as an isolated leader.
Single side arrow

inbound only or outbound only

The client has a neighborhood list of peers but has not established a peer connection. This state generally results from a misconfiguration, such as when a host-based firewall on the endpoint does not allow inbound connections to the client.
Double side arrows

inbound and outbound connections

The client has a neighborhood list of peers and has connected with peers in the indicated direction.
Client state Normal

inbound and outbound connections

The client is communicating normally.
Blocked

blocked

The client is not communicating reliably. This might result from a network issue or host resource issue, such as an antivirus program that slows the client.

In a test or small pilot deployment, you might notice what seems like an inordinate number of leader connections or unexpected leader connections. The Tanium Core Platform performs better with a minimum number of leaders, so it creates them when necessary.

You can also use questions to verify expected behavior. The Taniumâ„¢ Default Content pack includes sensors designed to examine the Tanium Client peer communication settings: Tanium Client IP Address, Tanium Peer Address, Tanium Back Peer Address, and Tanium Client Neighborhood. The following example is a dynamic question that uses these sensors.

Figure  3:  Tanium Client peering sensors

Examine the Tanium Client configuration

You can check the peer address lists in the Tanium Client settings on an individual Tanium Client.

The following is an example of a Windows registry for a Tanium Client that has peering disabled through the isolated subnets configuration. The NeighorhoodList setting still lists peers, but their ports are set to 0 so that the client knows not to connect with them.

Figure  4:  Tanium Client settings in Windows registry

The following example shows CLI output for the neighborhood and peering information in the Tanium Client database (Tanium Client 7.2 or later).

cmd-prompt$ sudo ./TaniumClient config list
Keys:
  - ComputerID: 3235161864
  - DatabaseEpoch: 2017-11-01 17:54:19.073914
  - HostDomainName: tam.local
  - LastGoodServerName: ts1.tam.local
  - LogVerbosityLevel: 1
  - RegistrationCount: 3333
  - Resolver: nslookup
  - ServerName: zs1.tam.local
  - ServerNameList: ts1.tam.local,zs1.tam.local
  - ServerPort: 17472
  - Status:
    - Status.BackPeerAddress: 512:17472:10.10.10.40_512:0:10.10.10.40
    - Status.BackPreviousPeerAddress: NoAddress_NoAddress
    - Status.BufferCount: 2
    - Status.ClientAddress: 512:17472:10.10.10.51_512:0:10.10.10.51
    - Status.NeighborhoodList: 512:17472:10.10.10.13_512:0:10.10.10.13, 512:17472:10.10.10.40_512:0:10.10.10.40, 512:17472:10.10.10.51_512:0:10.10.10.51
    - Status.PeerAddress: NoAddress_NoAddress
    - Status.PreviousPeerAddress: 512:17473:10.10.10.11_512:0:10.10.10.11
    - Status.StaleCount: 34
    - Status.StaleList: Operating System,NAT IP Address,Online,OS Platform,Available Patches,Running Processes Memory Usage,Tanium Client Version,Disk Used Percentage,Reboot Required,Tanium Client Core Health,Is Virtual,Disk Free Space,tempsensor_33,Installed Applications,Comply - Compliance Aggregates,Has Tanium Standard Utilities,Has Incident Response Tools,Has Patch Tools,Installed Patches,Manufacturer,Has Hardware Tools,Is Windows,Chassis Type,Is Mac,IOC Detect Tools Version,Comply - Vulnerability Aggregates,Has Old Incident Response ID Files,Patch Cab Out of Date,IP Address,Uptime,Network Adapters,Is Linux,Open Ports,Running Processes
  - ValueSystem:
    - ValueSystem.0 0: 1
    - ValueSystem.CorrelationDecisionHaste: 1
    - ValueSystem.CorrelationRequiredConfidence: 0.69999999999999996
    - ValueSystem.CorrelationThresholdMultiplier: 1
    - ValueSystem.CorrelationVolumeMultiplier: 0.01
    - ValueSystem.PrevalenceDecisionHaste: 1
    - ValueSystem.PrevalenceRequiredConfidence: 0.69999999999999996
    - ValueSystem.PrevalenceVolumeMultiplier: 1
    - ValueSystem.ValueThreshold: 0.10000000000000001
  - Version: 7.4.2.2073
cmd-prompt$

Randomize listening ports

In deployments where you want to make it harder for people to make packet captures of encrypted traffic, configure the Tanium Client to randomly select a new listening port at intervals. The client uses the listening port to receive communications from peer clients that are in the same linear chain. By default, randomization is disabled and the client uses 17472 as a fixed listening port.

You can configure port randomization during the initial Tanium Client deployment or afterwards. The following settings on the client control listening port behavior:

Table 2:   Tanium Client listening port settings
Setting Description
EnableRandomListeningPort Set the value to 1 to enable or 0 (default) to disable port randomization. If another application is already using the selected port, the client selects another port immediately instead of waiting for the RandomListeningPortTTLInHours interval.

If you change EnableRandomListeningPort from enabled to disabled, you must also remove the ListenPort setting or set it to the desired port. Otherwise, the port that the client last randomly selected before you disabled EnableRandomListeningPort becomes the permanent listening port.

RandomListeningPortMin Specify the low end of the range of ports from which the client randomly selects a listening port. The default is port 32000.
RandomListeningPortMax Specify the high end of the range of ports from which the client randomly selects a listening port. The default is port 64000.
RandomListeningPortTTLInHours Specify the interval in hours at which the client selects a new listening port. The default is 24 hours. Do not set the value lower than the client reset interval, which by default is a random interval in the range of 2 to 6 hours.
RandomListeningPortExclusions Specify ports that the client must never select as a listening port. For example, to prevent port competition conflicts, you might specify ports that other applications use. For multiple exclusions, use a comma to separate each port. By default, the client does not exclude any ports that are within the range that the RandomListeningPortMin and RandomListeningPortMax settings define.
ListenPort This setting indicates the current listening port. If you enable port randomization, do not configure ListenPort because the client overwrites the value whenever it selects a new port.

Before you begin

Work with your network administrator to configure your endpoint firewalls to allow incoming connections on any port that the Tanium Client process requests. The process is TaniumClient.exe on Windows endpoints and TaniumClient or taniumclient on other endpoints.

Randomize listening ports during client deployment

The steps to randomize listening ports depend on the tool that you use to deploy Tanium Clients.

Tanium Client Management service

Add the EnableRandomListeningPort setting and set it to 1 when you configure client settings in the Tanium Client Management service. To use non-default values for the other port randomization settings in Table 2 (except ListenPort), add those settings also. For the procedure, see Tanium Client Management User Guide: Configure client settings.

You can use Client Management to deploy the client only to Windows, macOS, and Linux endpoints.

All other client deployment tools

Configure EnableRandomListeningPort during the step to configure additional client settings in the corresponding deployment procedure. To use non-default values for the other settings in Table 2 (except ListenPort), configure those settings also. For the procedures, see:

You can configure the settings through the following CLI command on all endpoints or in the TaniumClient.ini file (if it exists) on macOS endpoints:

TaniumClient config set <setting> <value>

Randomize listening ports after client deployment

Perform the following steps to enable the EnableRandomListeningPort setting on all Tanium Clients that must randomize their listening port. Repeat the steps for each setting in Table 2 (except ListenPort) that requires a non-default value. Because Windows and non-Windows endpoints require separate packages to update settings, repeat the steps for both types of endpoints.

  1. Go to the Tanium Home page and issue a question that identifies the endpoints that require updated port randomization settings.

    The following question identifies endpoints where the EnableRandomListeningPort setting is disabled (1) or not configured (Key/Value not found):

    Get Tanium Client Explicit Setting[EnableRandomListeningPort] and Is Windows from all machines

  2. In the Question Results grid, select the Windows or non-Windows endpoints (not both) that need updated settings and click Deploy Action.
  3. Configure the package settings:
    • Deployment Package: Select Modify Tanium Client Setting for Windows endpoints or Modify Tanium Client Setting [Non-Windows] for other endpoints.
    • RegType: Select REG_DWORD.
    • ValueName: Enter the setting name ( such as EnableRandomListeningPort).
    • ValueData: Specify the setting value as described in Table 2 (such as 1 to enable the EnableRandomListeningPort setting).
  4. (Optional) In the Schedule Deployment section, set a schedule for the action.

    Set a reissue interval if some target endpoints might be offline when you initially deploy the action.

  5. In the Targeting Criteria section, ensure that the settings target only the endpoints that:
    • Require the updated setting
    • Correspond to the selected package (Windows or non-Windows)
  6. Click Show preview to continue and verify that the targeting is correct.
  7. Click Deploy Action and review the action status to verify that the action completes without errors.
  8. Issue a question to verify that clients have the correct setting value.

    The following question displays the EnableRandomListeningPort value for clients:

    Get Tanium Client Explicit Setting[EnableRandomListeningPort] from all machines

    Clients do not apply the updated setting until you manually restart them or wait for the automatic client reset, which by default is a random interval in the range of 2 to 6 hours.

  9. (Optional) Restart the Tanium Client service on each endpoint to apply the updated setting immediately: