Tanium: desplegar el cliente, preguntar en tiempo real, parchear, instalar software y un equipo que devuelve datos antiguos

Qué vas a conseguir

Un Tanium en el que todos los equipos tienen el cliente sano, en el que preguntas "qué equipos tienen esta versión de esta aplicación" y te responde en segundos, en el que los parches se instalan en ventanas acordadas y el software se despliega sin pasar por otra herramienta. Y el método para el ticket que más confunde al principio: un equipo que aparece en Tanium, pero con datos que no cuadran con lo que tiene de verdad.

Antes de empezar

• Un usuario de la consola con un rol que permita preguntar, desplegar acciones y administrar Patch y Deploy en los grupos de equipos que te tocan (en Tanium los permisos se dan por rol y por computer group).
• Salida de los equipos al servidor o a Tanium Cloud por el puerto TCP 17472, que es el que usa el cliente. Si hay proxy o cortafuegos de por medio, este puerto se abre explícitamente.
• Los computer groups definidos: por sistema operativo, por sede, por función (servidores, puestos, equipos de sala de trading). Todo lo que haces después se apunta a un grupo.

1. Desplegar el cliente

El instalador de Windows necesita, además del ejecutable, el fichero tanium-init.dat, que lleva la dirección del servidor y la clave pública para confiar en él. Se descargan juntos desde Client Management en la consola (o desde la página de despliegue de clientes de Tanium Cloud).

›.\SetupClient.exe /S /ServerAddress=tanium.contoso.local /ServerPort=17472# tanium-init.dat tiene que estar en la misma carpeta que SetupClient.exe›Get-Service "Tanium Client" | Select-Object Status, StartTypeStatus  StartType------  ---------Running Automatic

• En Intune, se empaqueta como aplicación Win32 con los dos ficheros y la regla de detección es el servicio o la carpeta C:\Program Files (x86)\Tanium\Tanium Client.
• En MECM, una aplicación con el mismo comando y un despliegue Required al grupo de recopilación de todos los equipos sin cliente.
• Client Management también puede instalar el cliente desde la consola en equipos que ya ve en la red, y es donde se mira la salud: versión del cliente, último registro y equipos que no se registran.

Si el cliente forma parte de la imagen maestra (MDT, OSD, plantilla de VM), hay que prepararlo antes de capturarla: parar el servicio y quitar su identificador único. Si no, todos los equipos clonados se presentan al servidor como el mismo. Es la causa número uno del problema de la sección 6.

2. Interact: preguntas con sensores

Un sensor es un pequeño script que el cliente ejecuta y que devuelve un valor: nombre del equipo, sistema operativo, aplicaciones instaladas, último usuario, espacio libre. Una pregunta combina sensores y filtros, y la responden todos los equipos a la vez en segundos, porque el resultado viaja de equipo a equipo en el linear chain en vez de pasar cada uno por el servidor.

• El contador de N equipos han respondido es parte de la respuesta: los que faltan están apagados o sin conexión, y no aparecen en el resultado.
• Una pregunta útil se guarda como Saved Question y se programa para que recoja resultados: es la base de los informes.
• Desde un resultado se lanza una acción (un package) a esos equipos: reiniciar un servicio, recoger un log, desinstalar una versión. La acción queda registrada con quién la lanzó y a qué equipos.

Antes de lanzar una acción a "todos los equipos del resultado", filtra por un computer group concreto y prueba con dos o tres. Una acción mal escrita llega a mil equipos con la misma rapidez que una buena.

3. Patch: listas, despliegues y ventanas de mantenimiento

Patch trabaja con cuatro piezas que conviene separar:

• Patch lists: qué parches se instalan. Por ejemplo, "Windows 11 - acumulativas del mes" construida con reglas (gravedad, producto, fecha de publicación).
• Block lists: qué parches no se instalan nunca en ciertos equipos (un controlador que rompe una aplicación de trading, una versión de .NET que una aplicación no admite todavía).
• Deployments: cuándo y a qué grupo se aplica una lista, con su hora de inicio, su fin y lo que se hace con los reinicios.
• Maintenance windows: las horas en las que un grupo puede instalar y reiniciar. Fuera de ellas, Patch no instala aunque haya un despliegue activo.

Un orden de anillos que funciona: equipos de IT el martes de parches, un piloto de cada departamento a los tres días, el resto la semana siguiente y la sala de trading en su ventana de fin de semana. El informe de cumplimiento por grupo (equipos con parches pendientes por antigüedad) es lo que llevas a la reunión semanal.

4. Deploy: software sin pasar por otra herramienta

Deploy instala, actualiza y desinstala aplicaciones con software packages (el instalador, el comando y la regla de detección) y despliegues a computer groups, igual que Patch. Tanium ofrece una galería de paquetes de aplicaciones conocidas que se importan ya preparados, y tú añades los propios.

• La regla de detección decide si la aplicación "está": si es floja (solo la carpeta), Deploy da por instalada una versión rota.
• Para el caso de Zoom de la sección 2: un despliegue de actualización a los equipos que respondieron con una versión anterior, en lugar de a toda la empresa.

5. Comply: lo básico

Comply evalúa los equipos contra estándares de configuración (benchmarks de CIS o de DISA) y busca vulnerabilidades por CVE. Los resultados se ven por equipo, por regla y por CVE, y se cruzan con Patch: muchas vulnerabilidades de Windows se cierran con la acumulativa que ya tienes en una lista.

• Empieza con un estándar y un grupo pequeño: un benchmark completo sobre todos los equipos genera miles de hallazgos que nadie va a leer.
• Si ya usas otro escáner (Qualys, por ejemplo), decide cuál es la fuente de verdad para vulnerabilidades y usa el otro para contrastar. Dos cifras distintas en la misma reunión no ayudan.

6. El ticket: "en Tanium este equipo sale con datos que no son"

Un técnico pregunta por MAD-PC-0419 y Tanium dice que tiene Windows 10 y Zoom 5.17. El usuario jura que le actualizaron a Windows 11 la semana pasada. Se mira en este orden:

1. ¿Ha respondido ahora o es un dato recogido? Si la respuesta viene de datos guardados (resultados recogidos de una Saved Question o del servicio de datos de Tanium), puede ser del último día que el equipo estuvo encendido. Mira la fecha del dato y pregunta en directo con el equipo encendido.
2. ¿El cliente se registra? En Client Management, la hora del último registro. Si es de hace días, el equipo no llega al servidor: el puerto 17472, el proxy o la VPN.
3. ¿Hay dos equipos con la misma identidad? Si el equipo salió de una imagen con el cliente sin preparar, dos o más equipos comparten identificador y sus datos se pisan: un día responde uno y otro día el otro. Se ve porque el mismo nombre o la misma identidad aparece con IP y usuarios que cambian.
4. ¿El cliente funciona en el propio equipo? Servicio arrancado, versión y servidor al que apunta.

›cd "C:\Program Files (x86)\Tanium\Tanium Client"›.\TaniumClient.exe config get ServerNameListtanium.contoso.local›.\TaniumClient.exe config get ComputerID1438845210›Get-Content .\Logs\log0.txt -Tail 20# busca errores de conexión o de registro en las últimas líneas

Si el identificador está duplicado, la solución es la misma que en la imagen: parar el servicio, borrar el identificador y arrancarlo, para que el cliente se registre como nuevo.

›Stop-Service "Tanium Client"›.\TaniumClient.exe config remove ComputerID›Start-Service "Tanium Client"

No lo hagas en todos los equipos "por si acaso": se pierde la relación con el historial del equipo en algunos módulos. Solo en los que tienen la identidad duplicada, y corrige la imagen para que no vuelva a pasar.

Siguientes pasos

• La guía de Qualys cubre el escaneo de vulnerabilidades con agente y la priorización con KEV; con Tanium al lado, decide cuál es la fuente de verdad.
• MECM / SCCM: empaquetado de aplicaciones es útil para el instalador del cliente y para comparar Deploy con lo que ya haces en MECM.
• El informe de cumplimiento de parches por grupo es evidencia de auditoría. Es la idea del repositorio 25-security-controls-evidence de mi GitHub: reunir en un sitio la prueba de que cada control se cumple.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.