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 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 resource use over the wide area network (WAN).

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

You can 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.

Use the default client peering settings to optimize network resources when all endpoints on a subnet defined by the default /24 address mask share a high-speed local connection, or when you do not have much information about the enterprise network. Work with network administrators and Tanium Support to configure a few key settings that further optimize peer communication based on the characteristics of your 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 setting is (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: Specify more granular exceptions to the boundaries that the address mask or prefix setting defines. For example, within a subnet that the address mask setting defines, you might have a smaller subnet that crosses WAN links. In this case, you can define separated subnets within that smaller subnet so that its clients do not peer across the WAN links. For more information, see Configure separated subnets.
  • Isolated subnets: Specify the addresses of subnets and endpoints for which you want to disable Tanium Client peering. You can configure isolated subnets that are standalone subnets or that comprise smaller linear chains within the chain that the address mask or prefix setting defines (see Figure  1). For more information, see Configure isolated subnets.

When a Tanium Client registers through Tanium as a Service (TaaS) the Tanium Server or Zone Server, TaaS the server evaluates peering settings and applies the most restrictive rule to determine the subnet for that client. For example, if the default address mask defines a /24 subnet, and the separated subnets configuration defines a /26 subnet, TaaS the server applies the peering boundaries of the separated subnet to a client that has an IP address within the bounds of both.

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

Tanium Core Platform 7.2 or earlier supports only IPv4. Contact Tanium Support if you need IPv6 support in version 7.3 or later. 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 a deployment with separated and isolated subnets an IPv4 deployment where internal Tanium Clients connect with Tanium Servers in an active-active deployment and external clients connect with the Zone Server.

1 Address mask AddressMask and zs_address_mask

When each Tanium Client registers, TaaS 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 /24 subnet boundaries that the address mask setting AddressMask or zs_address_mask setting defines. In this example, both settings apply the default /24 address mask 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, TaaS applies the Tanium Servers and Zone Server apply exceptions that define smaller linear chains that are contained within the /24 address mask AddressMask or zs_address_mask chains.

3 Isolated subnets configuration

TaaS evaluates 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.

The following figure shows the Tanium database on a dedicated host. However, in a Tanium Appliance deployment, the database is on the same host as the Tanium Servers.

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 where Tanium Clients register directly 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 where Tanium Clients register with a 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 where Tanium Clients register directly 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 where Tanium Clients register with a 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 default /24 subnet boundaries that the address mask or prefix settings define (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 AdminAdministrator 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 a deployment includes Zone Servers, copy entries from the text field to the clipboard to use when you configure separated subnets on a Zone Server.

  4. Click Save.

Configure separated subnets on a Zone Server

If a 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 the 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 directory of each Zone Server (the default installation directory 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 in to 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, TaaS 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.

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 the deployment includes Zone Servers, copy entries from the text field to the clipboard to use when you configure isolated subnets on a Zone Server.

  4. Click Save.

Configure isolated subnets on a Zone Server

If the deployment includes Zone Servers, perform one of the following procedures, depending on whether you want to isolate all clients or clients on specific subnets, and your Tanium infrastructure.

The Zone Server applies the most restrictive rule to determine the subnet for a client. If you configure the zs_address_mask or AddressMask setting to isolate clients, that setting overrides any subnet-based isolation that is configured in an IsolatedSubnets.txt file.

Isolate all clients connected to any Zone Server

Set the zs_address_mask global setting on the Tanium Server (Administration > Management > Global Settings) to 4294967295, which specifies /32 subnet boundaries (single hosts) for all Zone Servers.

For more information, see Address mask and prefix settings.

Isolate all clients connected to a particular Zone Server

  1. Sign in to the Zone Server host as an administrator user.
  2. Access the CLI (see Tanium Core Platform Deployment Reference Guide: Command-line interface).
  3. Navigate to the Zone Server installation folder:

    > cd <Zone Server>

  4. Configure the AddressMask local setting to specify /32 subnet boundaries (single hosts):

    > TaniumZoneServer config set AddressMask 4294967295

For more information, see Address mask and prefix settings.

Isolate clients on specific subnets with 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 the 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 directory of each Zone Server (the default installation directory 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.

Isolate clients on specific subnets with Tanium Appliance infrastructure

  1. On the Zone Server appliance, sign in to 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

The Client Status page displays information about the state of Tanium Client registration and connectivity, and enables you to deploy actions to remediate issues.

To see the Client Status page and filter its grid, you require a role with the Read Client StatusRead System Status permission. Users with the AdminAdministrator reserved role have this permission.

View the status of Tanium Client registration and communication

  1. From the Main menu, go to Administration > Configuration > Client StatusAdministration > Management > Client Status.
  2. (Optional) To display status details only for specific Tanium Clients, edit the default filter settings, such as the registration intervals and connection status.


The following table lists the information that the Client Status page displays for each Tanium Client:

 Table 1: Client Status columns
Column Description
Host Name Endpoint host name.
Network Location (from client) Client IP address returned from a sensor on the client.
Network Location (from server) Client IP address recorded on the Tanium Server or Zone Server during the last registration.
Direction A circle represents the client and arrows represent its connections. For a list of possible connection states, see Table 2.
Valid Key No indicates an issue with the public key that the Tanium Client uses to secure communication with other Tanium Core Platform components. To resolve the issue, reinstall the Tanium Client (see Deploying the Tanium Client) or redeploy the key (see Download infrastructure configuration files (keys)).
Send State
  • Normal: The client is sending data to its backward and forward peers.
  • None: The client is not sending data to its forward or backward peers.
  • Forward Only: The client is sending data to its forward peer but not to its backward peer.
  • Backward Only: The client is sending data to its backward peer but not to its forward peer.
Receive State
  • Normal: The client is receiving data from its backward and forward peers.
  • None: The client is not receiving data from its forward or backward peers.
  • Next Only: The client is receiving data from its forward peer but not from its backward peer.
  • Previous Only: The client is receiving data from its backward peer but not from its forward peer.
Status
  • Normal: The client is communicating normally.
  • Slow Link: The client has connections with abnormally slow throughput.
  • Leader: The client is communicating with the Tanium Server or Zone Server because it is a backward leader, a forward leader, a neighborhood leader, or a client with no peer connections (such as a client in an isolated subnet).
  • Blocked: The client is not communicating reliably.
Last Registration Date and time when the Tanium Client last registered with the Tanium Server or Zone Server.
Protocol Version (hidden by default) Tanium Protocol version. For details about the protocol, see TLS communication.
Version Tanium Client version.

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

  • An up arrow indicates a connection with TaaS 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 why a Tanium Client is a leader and to identify connection issues. The following table lists the possible connection states:

 Table 2: 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 TaaS 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 anti-virus program that slows the client.

Export Tanium Client status details

Export information in the Client Status page as a CSV file or, if you have the AdminAdministrator reserved role, as a JSON file.

  1. From the Main menu, go to Administration > Configuration > Client StatusAdministration > Management > Client Status.
  2. Select rows in the grid to export information for specific Tanium Clients. If you want to export information for all clients, skip this step.
  3. Click Export Export.
  4. (Optional) Edit the default export File Name.

    The file suffix (.csv or .json) changes automatically based on the Format selection.

  5. Select an Export Data option: information for All clients in the grid or only for the Selected clients.
  6. Select the file Format: JSON (AdminAdministrator reserved role only) or CSV.
  7. Click Export.

    TaaSThe Tanium Server exports the file to the downloads folder on the system that you used to access the Tanium Console.

Copy Tanium Client status details

Copy information from the Client Status page to your clipboard to paste the information into a message, text file, or spreadsheet. Each row in the grid is a comma-separated value string.

  1. From the Main menu, go to Administration > Configuration > Client StatusAdministration > Management > Client Status.
  2. Perform one of the following steps:
    • Copy row information: Select one or more rows and click Copy Copy.
    • Copy cell information: Hover over the cell, click Options Options, and click Copy Copy.

Deploy actions to remediate client registration or connectivity issues

You can deploy actions to Tanium Clients to remediate issues that you observe in the Client Status page. For example, if you want certain clients to register with a Tanium Zone Server instead of the Tanium Server, you can deploy the Set Tanium Server Name List package to change the ServerNameList setting on those clients.

  1. From the Main menu, go to Administration > Configuration > Client Status.
  2. Select the Tanium Clients to which you want to deploy actions and click Deploy Action.
  3. Deploy the action.
  4. Review the Client Status grid to verify that the action produced the expected result.

Use questions to review peering settings

The Tanium™ Default Content pack includes sensors that you can use in questions to examine settings for Tanium Client peer communication:

  • Tanium Client IP Address
  • Tanium Peer Address
  • Tanium Back Peer Address
  • Tanium Client Neighborhood

The following example is a dynamic question that uses these sensors. Note that the results for the Tanium Client Neighborhood sensor display in the Backwards and Forwards columns:

Figure  2:  Sensors for peering information

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 to prevent the client from connecting with those peers.

Figure  3:  Peering information in Windows Registry

The following example shows CLI output for the neighborhood and peering information in the Tanium Client database:

$ sudo ./TaniumClient config list
Keys:
  - ComputerID: 3235161864
  - DatabaseEpoch: 2017-11-01 17:54:19.073914
  - HostDomainName: cloud.tanium.comtam.local
  - LastGoodServerName: taas-example1-zs.cloud.tanium.comzs1.tam.local
  - LogVerbosityLevel: 1
  - RegistrationCount: 3333
  - Resolver: nslookup
  - ServerName: taas-example1-zs.cloud.tanium.comzs1.tam.local
  - ServerNameList: taas-example1-zs.cloud.tanium.com,taas-example2-zs.cloud.tanium.comts1.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

Randomize listening ports

If you want to make it harder for people to capture packets from the encrypted traffic between Tanium Clients, 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.

By default, the port number for the Tanium Client API is one number greater than the client listening port. However, if you enable randomization for the listening port, the API port remains fixed at 17473.

One exception, with the following conditions, results in a different API port:

  • Installing the client on the same host as the Tanium Server or Zone Server

  • Using a randomized listening port

  • Using a port other than the default 17472 for Tanium traffic on the server

In this scenario, the client API port on the server host is one number greater than the server port. For example, if you change the Tanium Server ServerPort setting from the default 17472 to 17473, the client API port on the server host changes to 17474. Installing the client on the same host as a Tanium Core Platform server is not a best practice (see Compatibility between Tanium Core Platform servers and Tanium Clients).

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

 Table 3: Tanium Client listening port settings
Setting Description
EnableRandomListeningPort Specifies whether port randomization is enabled. Set the value to 1 to enable or 0 (default) to disable. 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 Specifies the low end of the range of ports from which the client randomly selects a listening port. The default is port 32000.
RandomListeningPortMax Specifies the high end of the range of ports from which the client randomly selects a listening port. The default is port 64000.
RandomListeningPortTTLInHours Specifies 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 Specifies ports that the client will not 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 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. For details, see ListenPort.
ServerPort Indicates the port that the client uses for communications with both the Tanium Server or Zone Server and with peer clients. ListenPort and EnableRandomListeningPort both override ServerPort for client-to-client communication. For details, see ServerPort.

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

Configure Tanium Clients to randomize the listening port by setting EnableRandomListeningPort during installation. For installation procedures, see Deploying the Tanium Client.

 Table 4: Methods to enable port randomization during deployment
Installation method OS Method to set EnableRandomListeningPort
Client Management Any

Include the EnableRandomListeningPort setting and set it to 1. To use non-default values for the other port randomization settings in Table 3, also add those settings. For more information, see Configure client settings.

Command-line interface (CLI) Windows

Specify the setting as one of the parameters of a silent installation:

SetupClient.exe /EnableRandomListeningPort=1 /S

To use non-default values for the other settings in Table 3, also include those settings as parameters.

Non-Windows

Run the following CLI command to configure ProxyServers during the step to configure Tanium Client settings:

./TaniumClient config set EnableRandomListeningPort 1

To use non-default values for the other settings in Table 3, also configure those settings.

Installation wizard Windows

Run the following CLI command to configure ProxyServers after completing the wizard:

TaniumClient config set EnableRandomListeningPort 1

To use non-default values for the other settings in Table 3, also configure those settings.

macOS

Add the EnableRandomListeningPort setting to the /Library/Tanium/TaniumClient/TaniumClient.ini file. For more information, see TaniumClient.ini.

To use non-default values for the other settings in Table 3, also include those settings.

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 3 that requires a non-default value (exclude ListenPort). 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 ask 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 either the Windows or non-Windows endpoints that need updated settings and click Deploy Action.

    Windows endpoints and non-Windows endpoints require different packages. If you are updating both Windows and non-Windows endpoints, complete this procedure separately for each group.

  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 (Windows only): Select REG_DWORD.
    • Type (non-Windows only): Select NUMBER.
    • ValueName: Enter the setting name ( such as EnableRandomListeningPort).
    • ValueData: Specify the setting value as described in Table 3 (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
    • Run the operating system that matches 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. Ask 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: