auditd — la caja negra del sistema y el identificador que no se puede cambiar

auditd es el demonio que recoge los eventos del subsistema de auditoría del núcleo y los escribe, por omisión, en /var/log/audit/audit.log. Dos tipos sostienen casi todo el trabajo del turno. EXECVE registra cada programa ejecutado con sus argumentos, igual que la creación de proceso de Windows. PATH y SYSCALL registran los accesos a archivos y las llamadas al sistema que alguna regla haya marcado.

La palabra clave es regla. Sin reglas, auditd apenas escribe nada útil: el detalle sale de las líneas de configuración que alguien escribió en /etc/audit/rules.d/. Cada regla lleva una etiqueta propia (-k), y esa etiqueta es el campo por el que se busca después. Un parque sin reglas de auditoría tiene el demonio corriendo y la caja negra vacía, que es una de las comprobaciones que un SOC hace al recibir una fuente nueva.

El uso más rentable de las reglas es la vigilancia de archivos: se marca una ruta y se pide que quede constancia de quién la lee, la escribe o le cambia los permisos. Las rutas que todo SOC vigila son siempre las mismas, porque son las que toca quien quiere quedarse: la configuración de permisos de administración, el archivo de contraseñas del sistema, las claves autorizadas de acceso remoto de cada cuenta y los directorios desde donde arrancan los servicios.

La gracia es que una vigilancia así no depende de que el intruso use una herramienta conocida. Da igual con qué editor, con qué comando o con qué script modifique el archivo: el evento se escribe igual, con la etiqueta de la regla, la ruta tocada y la cuenta que lo hizo. Es detección por objetivo, no por herramienta, y por eso envejece mucho mejor que una lista de nombres de programas.

Aquí está lo que hace a auditd distinto de todo lo demás en Linux. Cada evento trae tres identidades: el uid (quién es el proceso ahora), el euid (con qué permisos actúa) y el auid, el identificador de la sesión de acceso original. El auid se fija cuando la persona inicia sesión y no cambia aunque después use sudo, su o se convierta en administrador tres veces seguidas.

Esa es la respuesta a la pregunta más incómoda de cualquier incidente en Linux: «esto lo hizo root, pero ¿quién era root en ese momento?». Con el auid se responde con un dato, no con una suposición. Y hay un valor que conviene reconocer: 4294967295 —el entero sin signo que representa «sin asignar»— marca los procesos que no nacieron de un inicio de sesión, es decir, los servicios del propio sistema. Un comando interactivo con ese valor no es normal; un demonio arrancando con él, sí.

En la consola tienes los eventos de auditoría del bastión del-lnx-bast01 y del servidor de cargas. De madrugada hay varias ejecuciones con permisos de administrador y un par de archivos vigilados que cambian. Todos esos eventos comparten el identificador de la sesión de acceso de la que salieron. Encuéntralo.