Modulo 01. Cliente Tanium y ciclo de comunicacion

Objetivo del modulo

Comprender el papel del Tanium Client en la plataforma y el flujo básico de consulta, respuesta y ejecución de acciones.

Resultados esperados

• Describir qué hace el Tanium Client en el endpoint.
• Explicar cómo viajan las Questions y las respuestas.
• Identificar señales de salud o fallo del cliente.

Desarrollo teorico

El Tanium Client es el componente fundamental de toda la plataforma Tanium, porque sin él no existe visibilidad ni capacidad de acción sobre ningún endpoint. Se instala como servicio en Windows (Tanium Client Service), como daemon en Linux y macOS, y es responsable de participar en la cadena lineal (linear chain), ejecutar sensors, recoger resultados y aplicar acciones según los permisos y el contenido definidos en la consola. El binario del cliente es ligero, típicamente consume entre 20 y 40 MB de RAM en reposo, y se comunica exclusivamente a través del puerto TCP 17472, tanto para recibir instrucciones como para participar en la cadena de peers.

La arquitectura de comunicación de Tanium se basa en la linear chain, un modelo peer-to-peer donde los clientes se organizan en anillos lógicos. Cuando el Tanium Server emite una Question, esta no se envía individualmente a cada endpoint; en su lugar, el servidor la entrega a un grupo inicial de clientes que a su vez la propagan a sus vecinos dentro de la cadena. Cada cliente que recibe la Question ejecuta el sensor correspondiente, que es un script o binario que recoge información local del sistema operativo, del registro, del sistema de archivos o de cualquier fuente accesible. El sensor produce un resultado estructurado que viaja de vuelta por la cadena hasta el servidor, donde se agrega y se presenta al operador en la consola. Este modelo permite que Tanium alcance cientos de miles de endpoints en segundos, porque la propagación es distribuida y no depende de un servidor central bombardeando a cada nodo individualmente.

Los sensors pueden ser de distintos tipos. Los sensors paramétricos aceptan argumentos del operador para filtrar o personalizar la consulta, por ejemplo preguntando por un proceso concreto o una clave de registro específica. Los sensors de rendimiento deben escribirse con cuidado, porque un sensor mal optimizado que lea archivos grandes o ejecute operaciones costosas puede elevar el consumo de CPU del cliente y degradar la experiencia del usuario final. Tanium distribuye un conjunto amplio de sensors predefinidos a través de los Content Packs, pero las organizaciones pueden crear sensors personalizados usando VBScript, PowerShell, shell scripts o binarios compilados.

En el caso de las Actions, el flujo es similar en su inicio, pero en lugar de devolver datos, el cliente descarga el package asociado desde el servidor o desde un Tanium Relay cercano, verifica su integridad mediante hash, y ejecuta el contenido del package localmente. Un package puede contener scripts, binarios, archivos de configuración o cualquier recurso necesario para la remediación. La ejecución se rige por la Action Policy, que define el alcance (targeting), la ventana temporal, la fecha de expiración y si requiere aprobación previa. Esto implica que el cliente no es un simple listener pasivo; es un agente activo con lógica local que evalúa condiciones, gestiona descargas, ejecuta código y reporta resultados de ejecución.

Un punto crítico es la diferencia entre fallos de Question y fallos de Action. Una Question puede fallar porque el sensor tiene un error de sintaxis, porque el cliente no ha completado su registro inicial, porque la cadena está rota en ese segmento o porque el endpoint tiene un problema puntual de conectividad en el puerto TCP 17472. Una Action puede fallar por todas esas razones y además por problemas de descarga del package (firewall bloqueando la transferencia, Relay caído, espacio en disco insuficiente), por conflicto con software de seguridad del endpoint como antivirus o EDR que bloquea la ejecución del script, por restricciones del sistema operativo como políticas de AppLocker o SELinux, o por expiración de la ventana de ejecución antes de que el endpoint estuviera disponible. Por eso el troubleshooting del cliente debe distinguir claramente entre problemas de consulta, problemas de descarga de contenido y problemas de ejecución local.

La salud del cliente se monitoriza a través de varios indicadores. El servicio debe estar activo y arrancado correctamente. La versión del cliente debe ser compatible con la versión del Tanium Server y con el contenido desplegado; versiones antiguas pueden no soportar sensors o packages más recientes. El campo Last Registration indica cuándo fue la última vez que el cliente se registró con el servidor, y el campo Last Seen muestra la última comunicación exitosa. La participación en la cadena lineal se puede verificar observando si el cliente tiene peers asignados y si responde a Questions de forma consistente. Los logs del cliente, ubicados típicamente en la carpeta de instalación de Tanium, contienen información detallada sobre errores de conexión, fallos de descarga, problemas de certificado y errores de ejecución de sensors o packages.

En un entorno bien operado, una caída de cobertura del cliente en un segmento concreto dispara una investigación inmediata, porque afecta transversalmente a todos los módulos de la plataforma: Tanium Discover pierde visibilidad sobre esos endpoints, Tanium Patch no puede evaluar ni remediar vulnerabilidades, Tanium Threat Response pierde capacidad de detección y contención, y Tanium Comply no puede verificar configuraciones de seguridad. La cobertura del cliente se mide habitualmente comparando el número de clientes registrados y activos contra el inventario conocido del parque, y cualquier desviación significativa debe investigarse como un problema de primer nivel.

Contenido ampliado

Puntos clave

• El Tanium Client es la base real de la plataforma.
• Questions y Actions dependen del cliente, pero no fallan por las mismas causas.
• La salud del cliente debe medirse y revisarse regularmente.
• Sin cobertura de cliente no hay inventario ni remediación fiables.

Checklist operativa

• Verifica instalación, servicio y versión del cliente.
• Revisa última comunicación y respuesta a una Saved Question básica.
• Comprueba si existen errores repetidos de descarga o ejecución.
• Identifica segmentos con peor cobertura.

Errores frecuentes

• Asumir que cliente instalado equivale a cliente sano.
• No diferenciar fallo de consulta y fallo de acción.
• Olvidar el impacto de antivirus o controles de sistema.
• No monitorizar la versión del cliente a lo largo del tiempo.

Practica sugerida

Prepara una checklist de salud del Tanium Client para revisarla en una sede remota con mala cobertura.

Preguntas de autoevaluacion

• ¿Por qué el cliente es más que un simple agente pasivo?
• ¿Qué diferencia hay entre un fallo de sensor y un fallo de package?
• ¿Qué impacto tendría perder un 10 % de cobertura de cliente en un parque crítico?

Cierre

Entender el ciclo del Tanium Client ayuda a diagnosticar problemas desde la raíz y no solo desde el síntoma visible en consola.

Modulo 02. Topologia, zonas y proximidad

Objetivo del modulo

Diseñar la topología de Tanium teniendo en cuenta segmentación de red, sedes, zonas y cercanía operativa entre endpoints y componentes.

Resultados esperados

• Explicar cuándo y por qué usar zonas.
• Relacionar topología con latencia, cobertura y resiliencia.
• Detectar errores de diseño frecuentes en redes distribuidas.

Desarrollo teorico

La topología de Tanium define cómo se organizan y comunican los componentes de la plataforma: Tanium Server, Zone Servers, Relays y clientes. En una organización pequeña con red plana, un único Tanium Server puede gestionar toda la comunicación a través del puerto TCP 17472, y los clientes se organizan en la linear chain sin intermediarios adicionales. Sin embargo, en una empresa multinacional con sedes distribuidas, centros de datos separados, redes VDI, entornos DMZ y segmentos de servidores aislados, el diseño topológico se convierte en un factor determinante para la eficacia operativa de la plataforma.

El Tanium Zone Server es el componente que extiende la plataforma a segmentos de red que no pueden comunicarse directamente con el Tanium Server principal. Un Zone Server actúa como proxy entre los clientes de su zona y el servidor central, recibiendo las Questions, distribuyéndolas a los clientes locales y agregando las respuestas antes de devolverlas al servidor. Los escenarios típicos para desplegar Zone Servers incluyen sedes remotas separadas por enlaces WAN con ancho de banda limitado, redes DMZ donde los servidores expuestos no deben tener conectividad directa al servidor central, entornos de nube pública donde los endpoints están en VPCs separadas, y regiones geográficas con requisitos regulatorios de soberanía de datos. Cada Zone Server necesita conectividad TCP 17472 hacia el Tanium Server y acepta conexiones en el mismo puerto desde los clientes de su zona.

La configuración de zonas en Tanium se gestiona desde la consola mediante Zone Management, donde se definen las subnets o rangos IP que pertenecen a cada zona. Los clientes determinan su zona según su dirección IP y se conectan al Zone Server correspondiente. Es fundamental que la asignación de subnets sea precisa y no se solape entre zonas, porque un cliente asignado a la zona incorrecta puede experimentar problemas de latencia, pérdida de conectividad o fallos en la distribución de contenido. Cuando un cliente cambia de red, por ejemplo un portátil que se mueve entre oficinas, Tanium reevalúa su asignación de zona y lo redirige al Zone Server apropiado.

La proximidad entre componentes afecta directamente a tres aspectos operativos. Primero, la latencia de las Questions: aunque las preguntas son paquetes ligeros, si la cadena lineal tiene que atravesar enlaces WAN lentos para completar la propagación, el tiempo total de respuesta se degrada y los operadores ven resultados parciales o retrasados. Segundo, la distribución de contenido: cuando se despliegan Actions con packages grandes, como parches de sistema operativo que pueden pesar cientos de megabytes, cada cliente necesita descargar ese contenido. Si todos los clientes de una sede remota descargan el package desde el servidor central a través de un enlace WAN de 10 Mbps, el despliegue tarda horas y satura el enlace para el resto del tráfico corporativo.

Aquí es donde Tanium Relay se convierte en pieza clave. Un Relay es un cliente promovido que cachea localmente el contenido de los packages y lo sirve a los clientes cercanos. En una sede con 500 endpoints y un enlace WAN limitado, un Relay local permite que el package se descargue una sola vez desde el servidor central y después se distribuya localmente a velocidad de LAN. La selección de qué clientes actúan como Relay puede hacerse manualmente o mediante configuración automática basada en capacidad y ubicación. Es recomendable tener al menos dos Relays por ubicación significativa para garantizar redundancia.

El tercer aspecto es la resiliencia. Una topología bien diseñada debe contemplar qué ocurre si un Zone Server se cae o si un enlace WAN falla temporalmente. Los clientes tienen configurada una lista de servidores de respaldo (ServerNameList) que define a qué componentes intentan conectarse y en qué orden. Si el Zone Server primario no responde, el cliente intenta con el siguiente de la lista. En infraestructuras críticas se despliegan Zone Servers en alta disponibilidad con balanceadores o configuraciones activo-pasivo para minimizar el tiempo de pérdida de cobertura.

El diseño topológico también debe considerar los entornos VDI, donde cientos o miles de escritorios virtuales comparten la misma infraestructura de red. En VDI no persistente, los clientes Tanium se reinstalan o reconfiguran con cada inicio de sesión, lo que genera picos de registro masivo que el servidor y la cadena deben absorber. Para estos escenarios, Tanium ofrece configuraciones específicas como el Tanium Client para VDI, que optimiza el proceso de registro y reduce el impacto en la cadena lineal.

Finalmente, la documentación de la topología debe incluir un mapa actualizado de sedes, segmentos, Zone Servers, Relays, enlaces WAN con sus capacidades, reglas de firewall necesarias (TCP 17472 bidireccional entre todos los componentes relevantes) y la matriz de asignación de subnets a zonas. Este mapa es la referencia obligatoria para troubleshooting, para planificación de despliegues masivos y para auditorías de cobertura.

Contenido ampliado

Puntos clave

• La topología influye en velocidad, cobertura y estabilidad.
• Las zonas no son solo una cuestión de red; también de operación y seguridad.
• La proximidad correcta reduce tráfico y acelera acciones.
• El diseño debe partir del entorno real y no de un esquema genérico.

Checklist operativa

• Mapea sedes, segmentos y enlaces críticos.
• Decide dónde necesitas zonas o relays.
• Revisa requisitos de firewall y routing.
• Valida qué segmentos son más sensibles a latencia.

Errores frecuentes

• Diseñar la topología sin conocer el parque real.
• Olvidar redes remotas o segmentos aislados.
• Usar diseño único para sedes muy distintas.
• No revisar impacto WAN de acciones masivas.

Practica sugerida

Dibuja una topología Tanium para una empresa con HQ, 20 delegaciones, una red VDI y una red de servidores segregada.

Preguntas de autoevaluacion

• ¿Qué señales indican que una zona está mal diseñada?
• ¿Cuándo justifica una sede tener Relay local?
• ¿Qué relación hay entre topología y tiempo de remediación?

Cierre

La topología correcta convierte Tanium en una plataforma predecible; la incorrecta la vuelve frágil y costosa de operar.