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.

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 Technical Account Manager (TAM) to configure a few key settings that further optimize peer communication based on the details of your particular network. 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.

Tanium Core Platform 7.2 or earlier supports only IPv4. If you need IPv6 support in version 7.3 or later, consult your TAM. 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 zs_address_mask 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

Consult your TAM 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 (Console > Administration > 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 (Console > Administration > 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 zs_address_mask 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 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 (Console > Administration > 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. Consult your TAM 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 (Console > Administration > Global Settings). The default value is 0, which specifies no peering. If necessary, you can override the global setting by configuring zs_address_prefix_ipv6 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 boundary. Consult your TAM 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 servers.

In Tanium Core Platform 7.4.3 or later, Tanium Servers write subnet configurations to the Tanium database and automatically synchronize them. On Zone Servers, you must manually configure and maintain a SeparatedSubnets.txt file.

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.

After you configure separated subnets, Tanium Clients can take up to four hours (the client reset interval) to finish applying all the changes associated with the new configuration.

Figure  1 shows an example deployment with separated subnets.

Configure separated subnets on the Tanium Server

  1. From the Main menu, select Console > Configuration > Tanium Server and click 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.

    Tanium Core Platform 7.3 or later supports IPv6 subnets (consult your TAM). You must enter IPv6 subnets within square brackets followed by the prefix (such as [2001:db8::]/32).

    The following is an example:

    192.168.0.0/26
    192.168.2.0/26
    [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. Save your changes.

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 Console > Configuration > Tanium Server, click 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, log 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

As a best practice, do not enable Tanium Clients in VPNs to participate in client peering. VPN clients have local IP addresses in a special VPN address block, but their host endpoints are actually not close to each other. Network communication among VPN clients would use WAN links and have significantly greater latency than client-to-server connections. You can 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 so that the client does not participate in peering.

You might find it convenient to use isolated subnets to disable peering in other cases, such as for testing or debugging peering when underlying network issues exist. Note that disabling peering has performance costs (more client-server connections over the WAN) and issues with timeliness. As a result, isolated clients answer questions slower than peering clients. If you use isolated subnets to disable peering, the best practice is to investigate the underlying network issues, resolve them, and then update the configuration so that the isolated clients resume peering.

In Tanium Core Platform 7.4.3 or later, Tanium Servers write subnet configurations to the Tanium database and automatically synchronize them. On Zone Servers, you must manually configure and maintain an IsolatedSubnets.txt file. Each server uses the configuration to manage the peer list for Tanium Clients that register through it. After you configure isolated subnets, you do not have to restart the servers.

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.

After you configure isolated subnets, Tanium Clients can take up to four hours (the client reset interval) to finish applying all the changes associated with the new configuration.

If you install the Tanium Client on the Tanium Server or Zone Server host computer, 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.

Figure  1 shows an example deployment with isolated subnets.

Configure isolated subnets on the Tanium Server

  1. From the Main menu, select Console > Configuration > Tanium Server and click 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.

    Tanium Core Platform 7.3 or later supports IPv6 subnets (consult your TAM). You must enter IPv6 subnets within square brackets followed by the prefix (such as [2001:db8::]/32).

    The following is an example:

    192.168.0.0/26
    192.168.2.0/26
    [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. Save your changes.

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 Console > Configuration > Tanium Server, click 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, log 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 changes

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 Console > Administration > System 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.

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.

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

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.