Las tres lecciones anteriores han levantado un perímetro: red controlada, SSH con claves y sin root, cortafuegos con política de lista blanca y fail2ban bloqueando a quien insiste. Todo eso es prevención, y la prevención tiene una propiedad incómoda: cuando falla, no avisa. Un atacante que entra con una credencial legítima no dispara ninguna regla; su conexión aparece como established, igual que la tuya. Esta lección cambia la pregunta de «¿cómo impido que entren?» a «¿cómo me entero de que ya han entrado?», y responde con herramientas concretas: integridad de ficheros con AIDE, auditoría del kernel con auditd, lectura sistemática de los registros, auditoría de configuración con Lynis y un procedimiento de respuesta a incidentes que puedas seguir a las tres de la madrugada sin improvisar.

Advertencia legal previa. Todo lo que hay aquí es defensivo y se aplica sobre srv-tramontana, que es tu propia máquina de laboratorio. Escanear, sondear o intentar acceder a sistemas ajenos sin autorización escrita es un delito, con independencia de la intención. Y en el terreno del cumplimiento: detectar intrusiones en un sistema que trata datos personales de huéspedes activa obligaciones legales concretas —notificación de brechas en 72 horas bajo el RGPD— y monitorizar la actividad de personas trabajadoras tiene límites que no decide el administrador. Ambas cosas se tratan al final de la lección.

1. Por qué la detección es un control distinto de la prevención
2. Taxonomía: NIDS, HIDS, firmas, anomalías, IDS e IPS
3. Integridad de ficheros con AIDE
4. Automatizar AIDE con un timer de systemd
5. Detección de rootkits: rkhunter y chkrootkit
6. auditd: la auditoría del kernel
7. Análisis de registros para detección
8. NIDS: panorámica honesta de Suricata
9. Auditoría de configuración con Lynis
10. Respuesta a incidentes y obligaciones legales

Un control preventivo intenta que algo no ocurra. Un control detectivo asume que puede ocurrir y se ocupa de que no pase desapercibido. No son alternativas: son capas distintas, y una organización que solo tiene la primera se enteraría de un compromiso por una llamada de un tercero, semanas después.

Los cuatro caminos por los que la prevención de srv-tramontana puede fallar, hoy mismo:

La mentalidad que hay que adoptar se llama presunción de compromiso: no «¿estoy seguro?», sino «si estuviera comprometido, ¿cómo lo sabría?». Y esa pregunta se descompone en tres, que son las que estructuran toda la lección:

1. ¿Qué ha cambiado? Un atacante que quiere persistir tiene que modificar algo: un binario, un fichero de configuración, una clave autorizada, una unidad de systemd. → integridad de ficheros.
2. ¿Quién ha entrado? Toda sesión deja rastro en los registros de autenticación. → análisis de registros.
3. ¿Qué ha hecho? Qué ficheros se han leído o escrito, qué procesos se han lanzado. → auditoría del kernel.

El vocabulario del área es confuso porque mezcla tres ejes independientes. Conviene separarlos:

Las consecuencias prácticas de cada elección:

• Firmas: precisión alta, pocos falsos positivos, y ceguera total ante lo que no está en el catálogo. Necesitan actualización constante.
• Anomalías: pueden detectar lo desconocido, a cambio de falsos positivos y de necesitar un periodo de aprendizaje de lo que es «normal». Y «normal» cambia: la línea base que estableciste en 05-07 caduca.
• IPS: cuando se equivoca, provoca una interrupción del servicio. fail2ban, que ya tienes funcionando, es exactamente un IPS de propósito estrecho — y ya viste en 06-03 el riesgo de que te bloquee a ti.

Para un servidor único como srv-tramontana, la inversión que más rinde es un HIDS de integridad más auditoría del kernel. El NIDS gana valor cuando hay una red con varios equipos y un punto por el que pasa todo el tráfico; volveremos sobre ello.

La integridad de ficheros es la señal más fiable que tiene un servidor, por una razón estructural: un atacante que quiere persistir tiene que escribir en el disco. Puede borrar entradas de registro, puede falsear la salida de ps con un rootkit, pero el binario modificado o la clave añadida siguen ahí, y su huella criptográfica no coincide con la que tenías.

AIDE (Advanced Intrusion Detection Environment) construye una base de datos con los atributos y las sumas de comprobación de los ficheros que le indiques, y después compara el estado actual contra ella.

La configuración vive en /etc/aide/aide.conf y en los fragmentos de /etc/aide/aide.conf.d/. Lo esencial son los grupos de atributos, que definen qué se comprueba de cada fichero:

Se combinan con + en definiciones reutilizables, y luego se aplican a rutas con ruta grupo para vigilar y !ruta para excluir:

Fíjate en el criterio: el nivel de vigilancia se ajusta a lo que se espera que cambie. Vigilar el contenido de acceso.log con sha256 produciría una alerta cada minuto y en dos días habrías dejado de leer los informes — que es la forma más común de que un sistema de detección deje de servir para nada.

Y ahora el punto que decide si todo esto sirve de algo o es teatro:

Una base de datos de integridad que vive en el servidor vigilado no vale nada. Un atacante con privilegios de root modifica el binario, regenera la base de datos, y aide --check te dirá que todo está en orden. La base de datos —y, si te lo puedes permitir, el propio binario de aide— tiene que estar fuera de alcance: en un medio de solo lectura, o en otra máquina.

Como el runbook de recuperación que ya guardas fuera del servidor (05-08), la copia de referencia sale de la máquina:

Guardando al menos la suma de la base de datos fuera del servidor puedes detectar que la propia base de datos ha sido manipulada, que es el ataque contra el que hay que protegerse.

La notación es densa pero mecánica: la primera letra es el tipo (f fichero, d directorio, l enlace), y las posiciones siguientes indican qué atributo cambió (C contenido, p permisos, u propietario, s tamaño, m mtime). Un + en la columna significa que se añadió.

Y aquí está la habilidad de verdad, que no es leer el informe sino clasificarlo:

• Los dos ficheros cambiados son openssl y libssl. Tienes una explicación documentada: el 18/08 a las 06:12 unattended-upgrades aplicó la corrección de un CVE de TLS. Es un cambio legítimo, y se comprueba de forma independiente:

  $ grep -E 'openssl|libssl' /var/log/apt/history.log | tail -2
  Upgrade: libssl3t64:amd64 (3.0.13-0ubuntu3.4, 3.0.13-0ubuntu3.5), openssl:amd64 (3.0.13-0ubuntu3.4, 3.0.13-0ubuntu3.5)
  $ sudo debsums -c openssl
  # sin salida: todos los ficheros del paquete coinciden con el manifiesto de Debian
  

  debsums es la segunda opinión: verifica los ficheros instalados contra las sumas del propio paquete. Coinciden, así que el binario es el que Ubuntu publicó.

• El fichero añadido es otra cosa. authorized_keys2 es un nombre obsoleto que OpenSSH ya no lee por defecto, pero que en configuraciones antiguas sí, y nadie tenía motivo para crearlo. Esto no tiene explicación documentada, y es exactamente la forma de un mecanismo de persistencia. Aquí no se borra el fichero: se activa el procedimiento de respuesta a incidentes del final de la lección.

Tras validar los cambios legítimos, la base de datos se actualiza para que el próximo informe vuelva a estar limpio:

Existen alternativas: Tripwire es el ancestro de AIDE y tiene un modelo de firma criptográfica de su propia base de datos algo más robusto, a cambio de bastante más complejidad. debsums ya lo has visto y cubre solo ficheros de paquetes. Para un servidor único, AIDE es el equilibrio correcto.

Una comprobación que hay que recordar hacer no se hace. Con lo aprendido en 05-05, el patrón es directo, y respeta el principio de silencio si todo va bien:

Las 05:40 no son arbitrarias: la copia de seguridad termina antes de esa hora y la purga se ejecuta los lunes a las 05:10, así que la comprobación de integridad ve un sistema en reposo y no compite por la E/S — el mismo razonamiento que aplicaste en 05-07 cuando moviste la copia a las 02:30. Nice=19 e IOSchedulingClass=idle son la garantía adicional.

Un rootkit es software que se instala tras el compromiso para mantener el acceso y ocultar su presencia, típicamente sustituyendo binarios del sistema (ps, ls, netstat) o cargando un módulo del kernel que miente al espacio de usuario. Es la razón por la que la regla de oro del final de esta lección existe: si el sistema miente sobre su propio estado, ninguna herramienta que corra dentro de él es de fiar.

Y aquí llega el aprendizaje real de estas herramientas: los dos avisos son falsos positivos, y saber por qué lo son es el trabajo.

• El primero es una limitación del parseo de rkhunter: tú sí configuraste PermitRootLogin no en 06-02, pero lo hiciste en un fichero de /etc/ssh/sshd_config.d/, que la herramienta no lee. Se verifica con la fuente autorizada, sshd -T, que muestra la configuración efectiva:

  $ sudo sshd -T | grep -i permitrootlogin
  permitrootlogin no
  

• El segundo se explica por la actualización de openssl: los binarios cambiaron después de que ejecutaras --propupd. Tras validarlo con debsums, se regenera la base de propiedades.

chkrootkit cubre un terreno parecido con otras heurísticas y es habitual que marque interfaces en modo promiscuo o procesos ocultos que en realidad son artefactos de la virtualización. La conclusión operativa es que estas herramientas son complemento, no núcleo: se ejecutan periódicamente, sus avisos se investigan uno a uno, y jamás se automatiza una acción a partir de ellos.

AIDE responde a «¿qué ha cambiado?», pero no a «¿quién lo cambió, cuándo y con qué proceso?». Eso es auditd, el subsistema de auditoría del kernel de Linux: registra llamadas al sistema y accesos a ficheros en el momento en que ocurren, con el usuario real, el usuario efectivo, el PID y el comando.

Las reglas persistentes van en /etc/audit/rules.d/, y augenrules las compila al arrancar:

Recuerda que en 05-02 pusiste chattr +i en app.conf. Mira lo que apareció:

Léelo despacio, porque contiene un incidente completo: el usuario luis intentó abrir app.conf en escritura con vim, y la llamada openat falló con EPERM. El atributo inmutable hizo su trabajo. Y —esto es lo que aporta auditd sobre cualquier otro control— el intento quedó registrado con nombre, hora, PID y comando, aunque no llegara a producir ningún cambio que AIDE pudiera ver.

No es necesariamente malicioso: lo más probable es que Luis quisiera subir max_conexiones para resolver los db_timeout y no supiera del chattr. Pero es un dato que antes no tenías, y la conversación que provoca —canalizar los cambios de configuración por desplegar-seguro en vez de editar a mano en producción— es exactamente el valor de un control detectivo.

Los informes agregados salen con aureport:

Y esa segunda línea vuelve a apuntar a lo mismo que AIDE detectó. Dos controles independientes señalando el mismo sitio es una señal fuerte.

auditd no es gratis. Cada regla añade trabajo en el camino de las llamadas al sistema, y una regla amplia sobre una ruta con mucha actividad puede degradar el rendimiento de forma perceptible y llenar el disco.

Vigila lo que importa, mide el volumen (du -sh /var/log/audit/) y controla la retención en /etc/audit/auditd.conf con max_log_file, num_logs y max_log_file_action. Y cuando la configuración esté cerrada, -e 2 al final de las reglas las hace inmutables hasta el próximo reinicio: ni root puede modificarlas, lo que impide que un atacante desactive la auditoría antes de actuar. El precio es que un cambio legítimo exige reiniciar.

Tienes journald persistente desde 05-06 y sabes manejar journalctl. Lo que falta es saber qué buscar. Estas son las señales que un administrador revisa, con la consulta que las obtiene:

Dos observaciones sobre estos resultados, que son las que convierten una consulta en una decisión:

• La línea 2 muestra que luis entró con password. Pero en 06-02 configuraste PasswordAuthentication no. Que esa autenticación tuviera éxito significa que hay una excepción en algún Match de sshd_config.d/, o que se aplicó a una interfaz que no revisaste. Es el asunto pendiente que dejó abierto 06-03, y ahora tiene evidencia: hay que resolverlo, no solo pedirle a Luis que use su clave.
• Los 47 intentos desde 203.0.113.44 ya están bloqueados por fail2ban, pero el recuento sigue siendo útil como línea base: si mañana son 4.700, o si aparecen desde un rango nuevo, el cambio de forma es la señal.

La técnica que estás aplicando es la misma del Módulo 3 —grep, awk, sort | uniq -c | sort -rn— sobre una fuente distinta. Y la razón por la que en 05-06 insististe en el journal persistente es esta: sin él, la consulta número 3 no tendría 30 días de historia que consultar.

Un aviso importante: los registros de la propia máquina son evidencia manipulable. Un atacante con root puede borrar entradas del journal. Por eso la centralización de registros que se mencionó en 05-06 no es un lujo organizativo: enviar los registros a otra máquina en el momento en que se generan es lo que impide que se borren a posteriori.

Suricata es el NIDS de referencia en software libre: inspecciona el tráfico de red, lo compara con un catálogo de firmas (el conjunto gratuito ET Open de Emerging Threats es el punto de partida habitual) y registra o bloquea las coincidencias.

Dónde se coloca determina lo que ve:

En modo IDS recibe una copia del tráfico y solo avisa. En modo IPS se sitúa en el camino del tráfico y puede descartar paquetes, con el riesgo asociado: si se equivoca o se cae, corta el servicio.

Y ahora la parte honesta, porque montar Suricata en srv-tramontana sería un error de criterio en este momento:

En una infraestructura de una sola máquina, el esfuerzo invertido en AIDE y auditd rinde bastante más. Cuando Tramontana crezca a varios servidores —y en 07-07 verás cómo—, el NIDS pasará a la lista.

Un eje distinto: en vez de detectar actividad, Lynis evalúa la configuración del sistema contra un catálogo de buenas prácticas y devuelve una puntuación con sugerencias.

Cómo leerlo, que es menos evidente de lo que parece:

• El índice de endurecimiento no es una nota académica ni tiene un valor «aprobado». Es una métrica de seguimiento: lo que importa es su tendencia y que no baje sin que sepas por qué. Un 68 en un servidor con propósito definido puede ser correcto; un 95 conseguido aplicando sugerencias sin entenderlas es peor.
• Las sugerencias no se aplican a ciegas. Lynis evalúa contra un perfil genérico y no conoce el propósito de tu máquina. Algunas de sus recomendaciones aquí serían activamente contraproducentes.

Un ejemplo real de cada categoría:

El resultado del ejercicio no es una puntuación alta, sino un informe con decisiones documentadas. Eso es lo que se entrega a Marta y lo que resiste una auditoría, mientras que «hemos aplicado todo lo que decía la herramienta» no resiste ninguna.

Lynis se ejecuta de forma recurrente —mensualmente, con su propio timer— y su índice se anota junto a la línea base de rendimiento de 05-07.

Tienes una detección real: un authorized_keys2 que nadie creó. Lo que hagas en los próximos veinte minutos determina si conservas la información necesaria para entender qué pasó. Este es el procedimiento, y el orden importa:

1. No apagues la máquina. Apagar destruye toda la evidencia que vive en memoria: procesos, conexiones abiertas, ficheros borrados pero aún abiertos, claves en claro. Aísla en su lugar: corta el tráfico con el cortafuegos o desconecta la interfaz de red virtual desde el hipervisor, conservando el acceso por consola.

2. Anota la hora y el hallazgo por escrito, fuera del servidor. A partir de aquí, cada acción se registra con su hora. Esta bitácora es lo que después permite distinguir tus propias huellas de las del atacante.

3. Preserva la evidencia volátil antes de tocar nada, guardando la salida fuera de la máquina:

   $ ss -tunap            # conexiones y a que proceso pertenecen
   $ ps auxf              # arbol de procesos completo
   $ sudo lsof -n         # ficheros y sockets abiertos
   $ sudo ls -l /proc/*/exe 2>/dev/null | grep deleted   # binarios borrados en ejecucion
   $ w; last -F | head -20
   $ sudo cp -a /var/log /media/evidencia/    # y el journal: journalctl -o export
   

   La última consulta es especialmente valiosa: un proceso cuyo binario ya no existe en disco pero sigue ejecutándose es una señal muy fuerte.

4. Toma una instantánea del disco con la máquina aún encendida. En tu VM es una operación del hipervisor; en LVM, un snapshot como el de 05-04. Esa imagen es la copia sobre la que se investiga, para no alterar el original.

5. Determina el alcance: qué se accedió, desde cuándo, y si hay datos personales implicados. auditd y el journal son las fuentes. La pregunta que hay que poder responder es si reservas.csv —con nombres de huéspedes— fue leído o exfiltrado.

6. Comunica. Marta primero, y en cuanto haya sospecha de acceso a datos personales, el responsable de seguridad y el de protección de datos. Esto no es una decisión técnica.

7. Recupera reinstalando.

La cadena de custodia es el concepto que sostiene los pasos 2 a 4: un registro de quién tuvo acceso a cada evidencia, cuándo y qué hizo con ella, junto a las sumas de comprobación que demuestran que no se ha alterado. Sin ella, la evidencia sirve para entender lo ocurrido pero no para sustentar una reclamación o una denuncia.

Un servidor comprometido se reinstala, no se limpia.

No es pesimismo profesional, es aritmética. Para «limpiar» tendrías que demostrar que has encontrado todos los mecanismos de persistencia: cada binario sustituido, cada unidad de systemd añadida, cada línea de crontab, cada clave autorizada, cada módulo del kernel, cada biblioteca precargada por LD_PRELOAD. Un atacante competente deja varios y algunos difíciles de encontrar. Y las herramientas con las que buscarías corren sobre el sistema que quizá te esté mintiendo.

Por eso todo el trabajo del Módulo 5 tiene un valor que no era evidente entonces:

• La copia con restic (05-08) permite restaurar los datos, no el sistema comprometido.
• El runbook guardado fuera del servidor contiene el procedimiento de reconstrucción.
• La configuración documentada —netplan, sshd_config, reglas de ufw, unidades de systemd, app.conf— permite reconstruir la máquina.
• El RTO de 8 horas que aprobó Marta es exactamente el presupuesto de tiempo de esta operación.

Reinstalar es la opción rápida y segura, no la drástica. Y la reconstrucción por código que verás en 07-06 con Ansible convierte estas 8 horas en bastante menos.

• Notificación de brechas (RGPD, art. 33). Si hay una violación de seguridad que afecta a datos personales, la organización debe notificarla a la autoridad de control en un máximo de 72 horas desde que tiene conocimiento de ella, y en algunos casos también a las personas afectadas. srv-tramontana guarda nombres de huéspedes en reservas.csv: el supuesto es plenamente aplicable. El plazo empieza a contar desde el conocimiento, no desde que acabas la investigación, así que la comunicación del paso 6 no puede esperar.
• Límites a la monitorización de personas. Las reglas de auditd que vigilan qué hace luis registran actividad de una persona trabajadora identificable. Eso está sujeto a la normativa laboral y de protección de datos: exige finalidad legítima, proporcionalidad, y —de forma determinante— información previa a las personas afectadas. Auditar en secreto la actividad del personal no es una decisión que corresponda al administrador.
• En un entorno real, tanto el diseño de la detección como cualquier decisión sobre una brecha deben revisarlos el responsable de seguridad y el de protección de datos. Este curso te da las herramientas técnicas; no sustituye ese criterio ni una auditoría formal.

Siguiendo la convención del curso —decir qué protege y qué no protege cada medida—, el entregable de esta lección:

Se corrige:

1. El authorized_keys2 no explicado: se activa el procedimiento de respuesta a incidentes; hasta cerrarlo, se asume compromiso.
2. La autenticación por contraseña de luis, que funciona pese a estar deshabilitada: hay una excepción en la configuración de SSH que hay que localizar y eliminar.
3. Los cambios de configuración hechos editando en producción: se canalizan por desplegar-seguro, y auditd verifica que se cumple.

Se asume, con motivo:

1. Sin NIDS, no hay visibilidad del tráfico de red. Se acepta mientras haya un único servidor; se revisa cuando haya varios.
2. Sin registros centralizados, un atacante con root puede borrar el journal. Se acepta con el coste actual; es la primera inversión cuando el presupuesto lo permita.

Qué protege esto y qué no. AIDE y auditd detectan cambios y accesos, y por tanto acortan el tiempo hasta detectar un compromiso, que es la variable que determina el daño. No lo impiden. Y ninguno de los dos protege contra un atacante que llegue con credenciales válidas y no modifique nada — para eso hace falta que los secretos dejen de estar donde están.

• Guardar la base de datos de AIDE solo en el servidor vigilado. Es el error que anula toda la medida. La base de datos, o al menos su suma de comprobación, tiene que estar fuera.
• Vigilar ficheros que cambian legítimamente con sha256. Produce un informe con cambios todos los días, y en una semana nadie los lee. La saturación de alertas es la principal causa de muerte de un sistema de detección: si suena siempre, no suena nunca.
• Actualizar la base de datos de AIDE sin investigar el cambio. aide --update después de cada informe convierte la herramienta en un registro de historia sin capacidad de alertar. Primero se clasifica cada cambio, luego se actualiza.
• Auditar demasiado con auditd. Una regla amplia sobre /var/log o /proc degrada el rendimiento y llena el disco. Empieza estrecho y amplía con criterio, midiendo du -sh /var/log/audit/.
• Confiar en un único control. AIDE detectó el fichero añadido y aureport lo confirmó de forma independiente. Dos fuentes que coinciden dan una confianza que ninguna da por separado.
• Apagar la máquina al detectar un compromiso. Es el reflejo natural y destruye la evidencia de memoria. Aísla la red, conserva la máquina encendida.
• Tratar los falsos positivos como ruido a silenciar. Cada aviso de rkhunter o Lynis que descartas debe quedar documentado con su motivo. Silenciar sin registrar es cómo se pierde el único aviso que era real.
• Consejo de método. Guarda las consultas de detección en un script (revision_seguridad.sh) que use lib/comunes.sh y se ejecute por timer. Una comprobación que depende de tu memoria no es un control.

Diseña la configuración de AIDE para vigilar /home/operador/bin/, el directorio que contiene el envoltorio desplegar-seguro con permisos 0755 de root. Justifica el grupo de atributos que eliges y explica qué ataque concreto detectaría tu regla que no detectaría vigilar solo la suma de comprobación del contenido.

Escribe la regla de auditd que registre cualquier ejecución del binario /home/operador/bin/desplegar-seguro, y la consulta de ausearch que muestre quién lo ha ejecutado hoy. Explica qué información aporta esto que no aporte ya el despliegue.log que escribe desplegar.sh.

aide --check informa de un cambio en /etc/tramontana/app.conf: el atributo de contenido y el mtime han cambiado, y los permisos han pasado de 640 a 644. Describe el procedimiento completo de investigación, indicando qué fuentes consultarías y en qué orden, y qué decisión tomarías en cada uno de los dos desenlaces posibles.

Solución 1

El grupo completo, y no solo sha256, por tres razones concretas, cada una asociada a un ataque distinto:

• p (permisos). desplegar-seguro está en la regla de sudoers como comando permitido a operador. Si un atacante consigue cambiarle los permisos a 0777, cualquier usuario del sistema puede reescribir su contenido y, a través de la regla de sudo, ejecutar código arbitrario con privilegios. El contenido no habría cambiado todavía, así que una regla que solo compruebe sha256 no vería nada. Este es el ataque que la respuesta debe identificar.
• u y g (propietario y grupo). El fichero debe ser root:root. Si pasa a ser propiedad de luis o del grupo tramontana, su dueño puede modificarlo sin necesidad de privilegios, y de nuevo el contenido aún coincide.
• i (inodo) y n (enlaces). Un cambio de inodo con el mismo contenido significa que el fichero fue sustituido, no editado —por ejemplo, reemplazado por un enlace simbólico a otro binario—. Un contador de enlaces que sube de 1 a 2 indica que alguien creó un enlace duro al fichero, lo que permite conservar acceso al binario original aunque se reemplace el que está en /home/operador/bin/.

En resumen: la suma de comprobación detecta la modificación del binario, pero los atributos detectan la preparación para modificarlo, que ocurre antes y es el momento en el que la detección todavía sirve para prevenir el daño.

Solución 2

Lectura de la regla: -a always,exit registra siempre, al salir de la llamada; -F arch=b64 la limita a binarios de 64 bits (necesario porque el filtro por path con perm opera sobre la arquitectura); -F path= es el fichero concreto; -F perm=x restringe el registro a las ejecuciones y no a las lecturas o escrituras; -k etiqueta el evento.

Qué aporta frente a despliegue.log, que es la parte de fondo del ejercicio. desplegar.sh escribe en su registro lo que él mismo decide escribir, y solo si llega a ejecutarse:

La diferencia esencial es de confianza: despliegue.log es el testimonio de la aplicación sobre sí misma; el registro de auditd lo genera el kernel, por debajo del proceso, y no depende de la buena fe ni del correcto funcionamiento de lo auditado. Además auditd conserva el auid —el usuario que inició la sesión original—, que sobrevive a los cambios de identidad por sudo y responde a «¿quién fue realmente?» cuando uid ya es root.

Solución 3

El cambio de permisos de 640 a 644 es lo relevante: significa que cualquier usuario del sistema puede ahora leer el fichero, y ese fichero contiene db_password en claro. Se trata igual que una credencial expuesta, exactamente como el incidente de la copia con permisos 644.

Procedimiento, en este orden y por este motivo:

1. auditd primero, porque responde a quién y cuándo, y es la fuente que un atacante tendría más difícil manipular:

   $ sudo ausearch -k tramontana_conf -ts today -i
   

   Busca el evento chmod/fchmodat con éxito y anota auid, uid, comm, exe y la hora exacta.

2. Correlaciona con las sesiones, para saber desde dónde llegó ese usuario:

   $ sudo journalctl -u ssh --since today | grep -E 'Accepted|Disconnected'
   $ sudo journalctl --since today | grep -E 'sudo:.*COMMAND'
   

3. Comprueba si hay una explicación legítima: ¿hubo un despliegue en esa ventana? ¿Coincide con apt?

   $ tail -20 /var/log/tramontana/despliegue.log
   $ grep -E "$(date +%Y-%m-%d)" /var/log/apt/history.log
   

4. Evalúa la exposición, que es la pregunta que determina la gravedad: durante cuánto tiempo el fichero estuvo legible, y si alguien lo leyó. El mtime cambiado indica además que el contenido también se modificó, así que hay que ver qué se cambió comparando con la última copia:

   $ sudo restic dump latest /etc/tramontana/app.conf | diff -u - /etc/tramontana/app.conf
   

   Y buscar lecturas del fichero en el intervalo:

   $ sudo ausearch -k tramontana_conf -ts recent -i | grep -E 'syscall=openat.*success=yes'
   

Desenlace A — cambio legítimo: el auid es operador, la hora coincide con un despliegue registrado, y el diff muestra solo max_conexiones ajustado. Aun así hay dos acciones obligatorias, porque el resultado es incorrecto aunque la intención fuera buena: restaurar chmod 640 y chown root:tramontana, y corregir la causa raíz —el procedimiento o el script que deja el fichero en 644— para que no se repita. Se documenta y se actualiza la base de datos de AIDE. La lección de fondo: un cambio autorizado con un resultado insegura sigue siendo un hallazgo.

Desenlace B — sin explicación, o auid inesperado, o diff con cambios que nadie reconoce: se trata como compromiso confirmado. Se aplica el procedimiento de respuesta a incidentes completo (aislar, no apagar, preservar evidencia volátil, instantánea del disco, determinar alcance, comunicar). Y con independencia de cómo acabe la investigación, la db_password se considera comprometida y se rota de inmediato, porque estuvo legible para todo el sistema durante un tiempo que no puedes acotar con certeza. Al haber datos personales implicados, la comunicación al responsable de protección de datos entra dentro del plazo de 72 horas.

En ambos desenlaces se llega a la misma conclusión estructural: mientras la contraseña esté en claro en un fichero de configuración, cualquier fallo de permisos es una fuga. Ese problema no se resuelve vigilando mejor el fichero.

Has pasado de un servidor que se defiende a un servidor que además se observa. AIDE vigila la integridad de la configuración, los binarios y los scripts, con su base de datos protegida fuera de la máquina y una comprobación diaria por timer que solo habla cuando hay algo que decir. auditd registra en el kernel quién toca app.conf, quién modifica identidades y privilegios, y quién intenta cargar un módulo — y ya te ha dado un hallazgo real que ningún otro control veía: el intento fallido de Luis contra un fichero inmutable. Sabes leer los registros buscando señales concretas en lugar de mirarlos por encima, sabes que rkhunter y Lynis se interpretan y no se obedecen, y tienes un procedimiento de respuesta a incidentes que no depende de la improvisación, con su regla incómoda incluida: un servidor comprometido se reinstala, no se limpia.

Y la detección ha hecho justamente lo que se le pide: te ha dicho dónde está el problema de fondo. Los tres hallazgos de esta lección apuntan al mismo sitio. El authorized_keys2 sin explicar, la sesión de luis autenticada por contraseña, y sobre todo la conclusión del último ejercicio: mientras la db_password viva en claro dentro de app.conf, cualquier fallo de permisos —tuyo, de un script, de un atacante— es una fuga de credenciales, y ninguna cantidad de vigilancia sobre ese fichero lo cambia. A eso se añade una segunda pieza que arrastras desde el Módulo 5: el tráfico de reservas, con los nombres de los huéspedes que tanto cuidado has puesto en proteger en las copias, sigue viajando sin cifrar por el puerto 8080. En la lección 06-05: Gestión de Secretos y Certificados TLS se resuelven las dos: sacarás la contraseña del fichero de configuración a un secreto cifrado que systemd entrega al servicio y nadie más puede leer, aprenderás a gestionar claves con GPG y pass y a cifrar en reposo con LUKS, y montarás el material criptográfico de reservas.tramontana.example —clave, CSR, certificado de Let's Encrypt y vigilancia de su caducidad— para que el día que el proxy inverso entre en juego en el Módulo 8 el cifrado en tránsito ya esté resuelto y verificado.