El control de integridad tiene una propiedad incómoda: necesita una referencia tomada de un sistema con certeza limpio. Si el servidor lleva tres años funcionando y la pregunta sobre una intrusión surge solo hoy, para esa referencia ya es tarde: registraría como normal lo que hay.

En Debian y Ubuntu, sin embargo, la referencia ya existe, y no es suya: cada paquete instalado lleva las sumas de verificación de sus propios archivos. La comparación no exige ni configuración ni instantánea previa y funciona en cualquier sistema en cualquier momento. La herramienta se llama debsums.

Uso

sudo apt install debsums
sudo debsums -c

La opción -c imprime solo los archivos que no coinciden con la referencia. Sin ella, la salida es un informe línea a línea de cada archivo del sistema, decenas de miles de líneas.

La comprobación tarda unos minutos y carga el disco, así que en un servidor en producción conviene ejecutarla con prioridad rebajada:

sudo ionice -c3 nice -n19 debsums -c

Cómo leer el resultado

Una salida vacía significa que todos los archivos comprobados coinciden con lo que instaló la distribución. Una salida no vacía exige análisis, y los hallazgos se dividen en dos clases muy distintas.

Archivos de configuración bajo /etc. Modificarlos es trabajo normal: editó sshd_config, configuró nginx, añadió parámetros del núcleo. Esas diferencias son esperables. Para que no estorben existe un modo aparte:

sudo debsums -e -c

-e comprueba solo los archivos de configuración: a veces resulta útil para ver la lista de todo lo que ha cambiado en esta máquina.

Ejecutables y bibliotecas. Una diferencia en /usr/bin, /usr/sbin, /bin o /usr/lib es justamente aquello para lo que se lanzó la comprobación. Hay causas legítimas, pero pocas: el archivo se editó a mano durante una depuración, se aplicó un parche ajeno, el paquete se estaba actualizando durante la comprobación. Si nada de eso encaja, toca investigar en serio.

Los objetivos clásicos de una sustitución son ls, ps, netstat, ss, find, sshd. Una versión sustituida oculta en su salida las líneas que importan, y todas sus comprobaciones posteriores dejan de decir la verdad.

La cobertura es incompleta, y hay que saberlo

Una limitación de la que no se suele hablar: no todos los paquetes traen sumas de verificación. Los archivos de esos paquetes no se comprueban en absoluto y no aparecerán en el informe bajo ninguna circunstancia. La lista se consulta así:

sudo debsums -l

Un informe limpio de debsums significa, por tanto, «en la parte comprobada todo está en orden» y no «el sistema no ha sido modificado». Lo mismo vale para todo lo instalado al margen del gestor de paquetes: compilado desde fuentes, descargado como binario, puesto por un script de la web del desarrollador; de eso debsums no vigila nada por definición, y ahí es donde hace falta AIDE.

Ejecución periódica

El paquete trae una tarea lista, activada en /etc/default/debsums:

CRON_CHECK=weekly

Una vez por semana es una frecuencia razonable: la comprobación carga el disco de forma apreciable y los archivos del sistema cambian poco entre actualizaciones. Ejecutarla a diario no aporta nada salvo carga.

Si un archivo ha sido sustituido de verdad

El primer impulso es reinstalar el paquete y recuperar el original:

sudo apt install --reinstall coreutils

El comando es correcto, pero no como primera acción. Un binario del sistema sustituido significa que alguien tuvo root, y restaurar el archivo no resuelve ese problema: solo destruye los rastros. El orden debe ser el inverso: primero guardar una copia del archivo sospechoso y su hora de modificación, mirar qué más cambió en ese mismo periodo, revisar las tareas de cron, las claves SSH y la lista de usuarios. Restaurar solo después.

Recuerde también los límites del método: si el sistema está profundamente comprometido, debsums y las bibliotecas que usa pueden haber sido sustituidos también. Una comprobación desde dentro no puede dar garantía absoluta: eso se hace arrancando desde un soporte externo. Para el trabajo diario, no obstante, basta: la inmensa mayoría de los ataques está automatizada y no tiene esa sofisticación.

Su lugar en el conjunto

debsums es valioso porque no exige nada y funciona de inmediato, lo que lo convierte en un punto de partida cómodo para un servidor cuya historia desconoce. Su debilidad es la cobertura incompleta y el desconocimiento de todo lo instalado fuera de los paquetes. El par «debsums más AIDE» cierra ambos lados: la referencia lista de la distribución para los archivos del sistema y su propia instantánea para lo demás.

Como siempre, la cuestión no es ejecutarlo, sino tener a la vista el último resultado con su fecha. Cómo se ve eso lo muestra la demostración de abajo.