Tareas programadas, servicios y claves SSH

Una tarea programada puede vivir en varios sitios a la vez. cron lee /etc/crontab, los archivos de /etc/cron.d y el crontab de cada cuenta en /var/spool/cron/crontabs. Pero systemd tiene su propio mecanismo: un temporizador (.timer) que activa un servicio (.service) a una hora o a intervalos. Un temporizador no aparece en ningún crontab; se lista con systemctl list-timers.

Por eso revisar solo cron deja fuera una vía entera, y revisar solo los temporizadores deja fuera otra. Una revisión de persistencia recorre todos los lugares y compara cada hallazgo con lo que la empresa instaló y aprobó.

Un paquete instala sus unidades en rutas del sistema, y dpkg -S dice a qué paquete pertenece un archivo; si responde que no encuentra la ruta, el archivo no vino de ningún paquete. Eso no basta para sospechar: la empresa puede haber creado unidades propias. La segunda comprobación es el registro de cambios: lo que una persona autorizada hizo consta ahí, y lo que no consta no tiene quién responda por ello.

Una unidad es sospechosa cuando cumple las dos condiciones a la vez: sin paquete y sin cambio aprobado. Una sola no alcanza, y esa distinción es la que evita acusar al temporizador legítimo de la empresa.

Cruza list-timers.txt, dpkg-propietarios.txt y registro-de-cambios.txt.

Una unidad de servicio dice qué se ejecuta, como quién y cuándo. En el .service, ExecStart indica el programa que se lanza y User la cuenta que lo ejecuta. En el .timer, OnBootSec marca cuánto tiempo después del arranque se activa por primera vez y OnUnitActiveSec cada cuánto vuelve a activarse desde la última vez. Con esos cuatro datos se describe el comportamiento completo del mecanismo sin ejecutar nada.

Lo importante para el informe es la combinación: un programa fuera de una ruta de sistema, lanzado con privilegios altos, con un intervalo corto que lo repite sin descanso, es un mecanismo diseñado para volver, no para dar servicio.

Abre la carpeta unidades: contiene el archivo del temporizador y el de su servicio.

Una línea de authorized_keys deja entrar sin contraseña a quien tenga la clave privada. El comentario de la línea (el texto final) lo escribe quien la añade y no demuestra nada: dos claves distintas pueden llamarse igual. Lo que identifica una clave es su huella (ssh-keygen -lf), un resumen que no se puede imitar. Se comprueba una por una contra el inventario de claves que la empresa mantiene.

Una huella que no está en el inventario es una clave que nadie dio de alta. Antes de borrarla se documenta: de qué cuenta es, cuándo se modificó el archivo, y qué opciones lleva en su línea.

Abre la carpeta claves: las líneas de authorized_keys, sus huellas y el inventario.

Una línea de authorized_keys puede llevar opciones antes de la clave. from="..." limita desde qué direcciones se acepta esa clave; command="..." fuerza a ejecutar un comando concreto. Se usan para endurecer un acceso legítimo, pero también las escribe quien planta una clave. La opción no hace buena a la clave: es información sobre quien la puso.

En este caso, la clave que no está en el inventario lleva una opción from= con una dirección. Esa dirección no es un detalle: es un dato más que enlazar con lo que ya sabes del incidente y que se puede buscar en los demás equipos.