Configuring Tanium Client peering

The Tanium™ platform is designed to optimize the network resources required to manage enterprise endpoints by distributing most of the data transmission among low latency, high bandwidth local area network (LAN) links, thereby dramatically reducing utilization over the wide area network (WAN).

The default settings are useful even when you do not have a lot of information about the enterprise network, and the default behavior delivers noticeable performance improvement over previous systems.

We recommend you work with your network administrators and Tanium technical account manager (TAM) to configure a few key settings that further optimize peer communication based on details of the particular enterprise network.

Tuning of Tanium Client peering settings should focus on the following objectives:

  • Always prevent client peering over the WAN. If you have a larger subnet, you might want to increase the address boundary set with AddressMask, but be sure your changes do not result in unacceptable latency. AddressMask should be set to the netmask for the biggest subnet in your network that you expect would not cross a WAN link.
  • Optimize neighborhood size as much as possible to reduce the number of leader connections.
  • Use the "separated subnets" configuration to specify more granular exceptions to the AddressMask boundary.
  • Use the "isolated subnets" configuration to specify the enterprise VPN subnet address(es). VPN clients should not participate in Tanium Client peering.

Default behavior

Out of the box, two Tanium Server settings determine the boundaries on Tanium Client peering:

AddressMask

A Tanium Server setting configured in the Windows Registry. AddressMask governs the network proximity of client peers in order to prevent suboptimal peer connections. The default setting 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 Tanium Clients register with Tanium Server, the server sends it a list of neighbors to which the client may attempt to peer. The neighbor list adheres to the AddressMask boundary.

DesiredNeighborhoodSize

A Tanium Core platform global setting that can be configured with the Tanium Console. By default, DesiredNeighborhoodSize is 100. This means that the Tanium Server manages Tanium Client peer assignment in such a way that the clients within the boundary of the /24 subnet form a linear chain of 100 clients, and then another chain of 100 clients, and so on. Each chain has one backward leader and one forward leader. On one end of the chain, the backward leader has the "lowest" IP address. Each forward peer has a "higher" IP address, but the IP addresses will not necessarily look like a contiguous block because not all systems with IP addresses in the subnet have the Tanium Client installed.

Figure  1:  A Tanium Client neighborhood in an enterprise subnet

In most cases, the default settings effectively prevent client peering over the WAN. For example, consider the enterprise network in the following figure. The default AddressMask setting (/24) is effective because it prevents peering over the WAN between enterprise clients in the Data Center and enterprise clients in Headquarters or the remote Branch office. The default DesiredNeighborHoodSize setting results in the formation of two neighborhoods per subnet.

Figure  2:  AddressMask /24

Example: Setting AddressMask to /22

In the example network, the default setting prevents peering across the two subnets in Headquarters. This boundary is acceptable, but perhaps unnecessarily restrictive because the clients are close enough to be good neighbors. Across Headquarters, peer connections are likely to experience low latency, few hops, and no hops over the WAN. If you were to allow peering across the Headquarters subnets, you could potentially reduce the overall leader count and consequently the number of WAN connections.

In this example, the enterprise network 192.168.0.0/22 comprises four /24 subnets, so you might consider setting AddressMask to /22 to permit peering across 192.168.1.0/24 and 192.168.3.0/24.

However, changing the AddressMask setting could have unintended consequences. For example, if you change AddressMask to /22, it would be possible for a client in the Data Center to be assigned a peer in the Branch or Headquarters subnets. You can use the "separated subnets" configuration to remedy the issue.

The separated subnets configuration sets boundaries at a more granular level than the AddressMask boundary. For example, you can create rules that restrict clients in 192.168.0.0/24 and 192.168.2.0/24 from peering outside their /24 subnets. When a Tanium Client registers, the Tanium Server evaluates both AddressMask and SeparatedSubnets.txt rules and applies the most restrictive rule. If the client is on a subnet listed in the separated subnets file, the Tanium Server manipulates the peer list provided to the client so that it includes only other clients in the same subnet.

Figure  3:  AddressMask /22 and SeparatedSubnets.txt

Note, however, that the leader count is not necessarily reduced by changing AddressMask alone. Typically, you should also increase DesiredNeighborhoodSize. Set it as large as you can without adding unacceptable latency. Keep in mind that the longer the chain, the longer the trip for a question that traverses it. A longer chain also means the client participates in shard distribution with a greater number of neighbors. After changing DesiredNeighborhoodSize, monitor the impact on question response time as well as client host computer resource utilization during scheduled actions. You might need to make additional adjustments to find the balance that is right for your particular network.

The following figure shows the impact of increasing DesiredNeighborhoodSize to 200. The number of leaders is reduced from 16 to 8.

Figure  4:  AddressMask /22, SeparatedSubnets.txt, and DesiredNeighborhoodSize=200

Configure the AddressMask setting

  1. On the Tanium Server host computer, go to the Windows Registry entry for Tanium Server:

    HKEY_LOCAL_MACHINE\Software\Wow6432Node\Tanium\Tanium Server

  2. Double-click the AddressMask entry to edit it. Refer to Table 1 for guidance on specifying values.
  3. Save your changes.

The following table summarizes IPv4 network address mask lengths for Class C and Class B addresses. AddressMask is a REG_DWORD type and is specified as a hexadecimal value. The convention dictates that the order of the octets in the mask is reversed in the Windows Registry key value, so FFFFFF00 (255.255.255.0) is specified as 00FFFFFF, and FFFFF000 (255.255.240.0) is specified as 00F0FFFF.

Table 1:   AddressMask settings
CIDR Mask Host Addresses Usable Addresses Netmask Hex Mask Windows Registry AddressMask value
          00000000
/30 4 2 255.255.255.252 FFFFFFFC FCFFFFFF
/29 8 6 255.255.255.248 FFFFFFF8 F8FFFFFF
/28 16 14 255.255.255.240 FFFFFFF0 F0FFFFFF
/27 32 30 255.255.255.224 FFFFFFE0 E0FFFFFF
/26 64 62 255.255.255.192 FFFFFFC0 C0FFFFFF
/25 128 126 255.255.255.128 FFFFFF80 80FFFFFF
/24 256 254 255.255.255.0 FFFFFF00 00FFFFFF
/23 512 510 255.255.254.0 FFFFFE00 00FEFFFF
/22 1024 1022 255.255.252.0 FFFFFC00 00FCFFFF
/21 2048 2046 255.255.248.0 FFFFF800 00F8FFFF
/20 4096 4094 255.255.240.0 FFFFF000 00F0FFFF
/19 8192 8190 255.255.224.0 FFFFE000 00E0FFFF
/18 16384 16382 255.255.192.0 FFFFC000 00C0FFFF
/17 32768 32766 255.255.128.0 FFFF8000 0080FFFF
/16 65536 65534 255.255.0.0 FFFF0000 0000FFFF
Enter eight zeros to disable the AddressMask setting. You would do this if you do not want to use AddressMask to limit peering. If you turn off AddressMask, there will be no default behavior, so you must explicitly account for all enterprise subnets in the SeparatedSubnets.txt file. Note that you must specify 00000000 and not just delete the registry key, or your changes will not persist across Tanium Server upgrades. If a registry entry named AddressMask does not exist, the upgrade process creates it with the default value (/24).

Configure DesiredNeighborhoodSize

  1. Log into the Tanium Console as a user with the Administrator role.
  2. Go to Administration > Global Settings.
  3. Search for the DesiredNeighborhoodSize setting.
  4. Select it and click Edit.
  5. Specify your custom size and save the configuration.
  6. Enter your password to commit the change to the database.

It can take up to four hours (Tanium Client registration reset interval) for clients to register and receive an updated peer list.

Configure "separated subnets"

The Tanium Console released with Tanium core platform 7.0.314.6194 includes a Configuration workbench to facilitate configuration of subnet settings.

To configure separated subnets (7.0.314.6194 and later):

  1. Go to Configuration > Tanium Server > Subnets.
  2. Use the Separated Subnets box to specify the CIDR address for subnets that should not allow client peering outside of the subnet.
  3. Use either the ; or # character at the beginning of a line or immediately following an entry to add optional comments or documentation.

  4. Save your changes.

To configure separated subnets (7.0.314.6085 and earlier version 7 builds):

  1. Create a text file using a standard editor such as Notepad.
  2. Within the file, specify subnet addresses in CIDR format, one entry per line. For example:

    # Datacenter subnets
    192.168.0.0/24
    ; Branch Subnets
    192.168.2.0/24


    Use either the ; or # character at the beginning of a line or immediately following an entry to add optional comments or documentation.

  3. Save the file with the name SeparatedSubnets.txt.
  4. Copy the file to the Tanium Server installation folder, including all Servers in an Active/Active cluster.
  5. Copy the file to the Zone Server installation folder on any Zone Servers. The Zone Server uses the list to manage the peer list for Tanium Clients that register through it. The content of the SeparatedSubnets.txt files can differ between servers. Only the local file has effect. We recommend you keep the files in sync to avoid the potential for confusion.

You do not have to restart the Tanium Server Windows Service.

It can take up to four hours (Tanium Client registration reset interval) for clients to register and receive an updated peer list.

Configure "isolated subnets"

Virtual private network (VPN) clients should not participate in Tanium Client peering. VPN clients are assigned local IP addresses in a special VPN address block, but the hosts are actually not in close proximity to each other. Network communication between them would utilize WAN and Internet links and would have significantly greater latency than client-to-server connections. You should configure the Tanium Server to treat clients belonging to VPN subnets differently.

Figure  5:  Isolated subnets

The "isolated subnets" configuration disables client peering for the specified list of subnet and host addresses. When a Tanium Client registers, the Tanium Server evaluates AddressMask, SeparatedSubnets.txt, and IsolatedSubnets.txt, and it applies the most restrictive rule. If the client IP address is in a subnet listed in the IsolatedSubnets.txt file, the Tanium Server manipulates the peer list provided to the client so that it is empty. Consequently, the Tanium Client does not participate in peering.

If you install the Tanium Client on the Tanium Server host computer, it may be appropriate to add the CIDR IP address for that host computer to IsolatedSubnets.txt. For example, 192.168.0.1/32. When installed on the same host as the Tanium Server, the Tanium Client is designed to automatically listen for peer traffic on port 17473 instead of 17472. You might encounter issues during client peering activities, such as file distribution, if port 17473 is blocked.

You might find it convenient to use the isolated subnets configuration to disable peering in other cases—for example, when testing or debugging peering when there are underlying network issues. Keep in mind that there are both performance costs associated with doing this (more client-server connections over the WAN) and issues with timeliness. For example, a Tanium Client that does not peer learns about new questions only at its registration interval—typically a number of minutes. As a result, isolated machines contribute answers more slowly than Tanium Clients that peer. If you use "isolated subnets" to disable peering, we recommend you investigate the underlying network issues, resolve them, and then update the configuration so that the isolated clients resume peering.

The Tanium Console released with Tanium core platform 7.0.314.6194 includes a Configuration workbench to facilitate configuration of subnet settings.

To configure isolated subnets (7.0.314.6194 and later):

  1. Go to Configuration > Tanium Server > Subnets.
  2. Use the Isolated Subnets box to specify the CIDR address for subnets in which clients should never peer.
  3. Use either the ; or # character at the beginning of a line or immediately following an entry to add optional comments or documentation.

  4. Save your changes.

To implement isolated subnets (7.0.314.6085 and earlier version 7 builds):

  1. Create a text file using a standard editor such as Notepad.
  2. Within the file, specify subnet addresses in CIDR format, one entry per line. For example:

    # Datacenter subnets
    192.168.10.0/24; Devices connecting through the VPN concentrator


    Use either the ; or # character at the beginning of a line or immediately following an entry to add optional comments or documentation.

  3. Save the file with the name IsolatedSubnets.txt.
  4. Copy the file to the Tanium Server installation folder, including all Servers in an Active/Active cluster.
  5. Copy the file to the Zone Server installation folder on any Zone Servers. The Zone Server uses the list to manage the peer list for Tanium Clients that register through it. The content of the IsolatedSubnets.txt files can differ between servers. Only the local file has effect. We recommend you keep the files in sync to avoid the potential for confusion.

You do not need to restart the Tanium Server Windows Service.

It can take up to four hours (Tanium Client registration reset interval) for clients to register and receive an updated peer list.

Verify changes

You can verify changes using the Tanium Console or by examining the configuration on the client host computer.

Use the Tanium Console

Tanium Clients receive updated peer lists during registration. Go to Administration > System Status to verify 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.

The Status column indicates whether the client is a leader. A blank entry indicates a normal peer. You can use the Status column to track how your configuration changes affect leader count.

The Direction column depicts client connection states. An up arrow indicates a connection with the Tanium Server. Side arrows indicate connections with peers. You can use the Direction column to understand the reasons the client is a leader.

Table 2:   Peer direction reported states
Icon Description
A client in normal state, with backward peer and forward peer connections.
A backward leader. Typically has a "low" IP address. It marks one end of a linear chain.
A forward leader. Typically has a "high" IP address. It marks one end of a linear chain.
A designated leader, due to the desired neighborhood size being reached.
Isolated client. An isolated client has no peer connections.

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

You can also use questions to verify expected behavior. The Initial Content pack includes sensors designed to examine the Tanium Client peer communication and neighborhood configuration. Sensors include: Tanium Client IP Address, Tanium Peer Address, Tanium Back Peer Address, and Tanium Client Neighborhood. The following example is an ad hoc question that uses these sensors.

Examine the client configuration

On an individual client, you can check the peer address lists in the Tanium Client settings.

The following is an example of a Windows Registry for a Tanium Client that has peering disabled via the IsolatedSubnets.txt file.

The following example shows the neighborhood and peering information in a TaniumClientStatus.ini file (Tanium Client 6.0). This client has no forward peer, so it is a forward leader.

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

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.2.314.2687
cmd-prompt$

Last updated: 7/31/2018 2:54 PM | Feedback