Talos

Por qué existe

Auditar el bastionado de un servidor casi siempre pasa por instalar algo. Y ahí empieza la conversación: si se puede, qué dependencias arrastra, quién firma que eso no va a tocar nada. En una empresa pequeña con un servidor en producción, esa conversación se alarga y la auditoría no se hace.

Yo quería un fichero que se copia, se ejecuta, escribe un informe y se borra. Sin instalador, sin intérprete y sin permisos de escritura en ningún sitio.

Cómo está hecho

Un binario en Go por sistema operativo, sin ninguna dependencia externa. Solo lee: no toca una clave del registro, no reescribe una configuración, no reinicia un servicio. Esa restricción está en el diseño desde el primer día, porque una herramienta capaz de arreglar cosas también puede romperlas y vuelve la conversación de quién firma.

El catálogo son 147 comprobaciones, 109 de Linux y 38 de Windows, y ninguna está en el código. Cada una es una ficha con su identificador, su severidad, su peso en la nota, los controles del Esquema Nacional de Seguridad que cubre y el texto de cómo arreglarla. Añadir una comprobación es añadir una ficha, así que lo puede hacer alguien que no sepa Go.

Aparte va un repertorio de vulnerabilidades críticas por versión. Compara la versión instalada de un paquete con la versión donde se corrigió el fallo en esa distribución, que no es la misma en Debian que en Ubuntu. Están PwnKit, Looney Tunables, regreSSHion, sudoedit, polkit, glibc iconv y CopyFail.

Y un informe HTML de un solo fichero, con filtros por severidad, tema claro y oscuro y hoja de impresión para que salga bien en PDF. De un solo fichero porque un informe con una carpeta de recursos al lado no se puede adjuntar en un correo.

Construido con agentes

Las 147 comprobaciones no las escribí a mano. Las saqué dirigiendo agentes de IA, que es una forma de trabajar distinta de pedirle código a un chat y pegarlo.

Las reglas van escritas como ficheros que el agente tiene que cumplir: qué formato tiene una ficha, qué campos son obligatorios y qué no puede escribir nunca. Encima de eso, comprobadores que rompen el build cuando alguna se salta.

El diseño del formato, el criterio de qué merece comprobarse y la verificación de que cada ficha dice la verdad son míos. El volumen de trabajo mecánico es de los agentes, y es la razón de que el catálogo llegue a 147 y no se quede en veinte.

El repertorio de vulnerabilidades por versión

Es la parte que más tiempo me llevó, y no por el código. Los rastreadores de seguridad de cada distribución dicen cosas distintas del mismo fallo, y comparar versiones de la forma ingenua da falsos positivos a puñados. Si el informe dice tres cosas críticas y dos no lo son, nadie se cree la tercera.

Verifiqué las entradas a mano contra los rastreadores de Debian y de Ubuntu, y las probé en contenedores de varias distribuciones hasta que dejaron de saltar donde no debían. Es trabajo lento y no tiene atajo.

Decisiones de diseño

Go y no Python. El requisito era un binario sin dependencias, y en Python eso significa empaquetar un intérprete.

Comprobaciones como datos. Cuesta más al principio, porque hay que diseñar un formato de ficha y un motor que lo lea. A cambio el catálogo crece sin recompilar, y sin que quien lo amplíe entienda el motor.

Solo lectura, sin excepciones. Hubo un momento en que pensé añadir un modo que arreglara lo trivial. No lo hice: la razón por la que alguien deja correr esto en producción es justamente que no puede hacer nada.

Pendiente

En Windows la herramienta solo audita y nunca remedia, y ahí el catálogo tiene menos comprobaciones que en Linux.