Los registros de Linux pueden revelar indicios de una intrusión mucho antes de que un administrador detecte sus consecuencias. Con journalctl, la herramienta de consulta de systemd-journald, es posible buscar conexiones de red inesperadas, instalaciones de software, creación de cuentas y posibles manipulaciones de los propios registros. Ninguna de estas señales demuestra por sí sola que exista un ataque, pero combinadas pueden ayudar a detectar comportamientos que merecen una investigación.
Las claves de los logs de Linux en 30 segundos
- Las conexiones de red inesperadas pueden revelar comunicaciones con sistemas desconocidos o actividad de procesos que no deberían salir al exterior.
- Instalaciones de paquetes fuera de las ventanas habituales pueden indicar que alguien ha añadido herramientas al servidor.
- Una cuenta nueva, especialmente con permisos elevados, puede proporcionar persistencia a un atacante.
- La ausencia repentina de registros también es una señal: un intruso con privilegios puede intentar borrar o alterar sus huellas.
journalctlno registra absolutamente todo, por lo que una investigación seria necesita combinarlo con otras fuentes de evidencia.
Revisar los registros no consiste en buscar una línea que diga que un servidor ha sido comprometido. El valor está en encontrar cambios o comportamientos que no encajan con lo esperado para esa máquina.
Un servidor puede establecer conexiones que son completamente legítimas, instalar paquetes durante una actualización o crear usuarios como parte de una tarea administrativa. El problema aparece cuando esos acontecimientos no tienen una explicación conocida o coinciden temporalmente con otros indicios.
Por eso journalctl resulta útil como punto de partida para investigar qué ha ocurrido y cuándo.
Conexiones de red que no deberían estar ahí
Una de las señales que conviene revisar son las conexiones de red inesperadas. Un atacante que ha conseguido acceder a un servidor puede intentar comunicarse con otra máquina, descargar archivos o establecer comunicación con un sistema remoto.
Una búsqueda sencilla en el journal puede localizar mensajes relacionados con conexiones:
sudo journalctl --grep="connection|connect|network"Lenguaje del código: JavaScript (javascript)También se pueden consultar mensajes del kernel:
sudo journalctl -k --grep="connection|network"Lenguaje del código: JavaScript (javascript)Y buscar eventos asociados a conexiones bloqueadas o rechazadas:
sudo journalctl --grep="DROP|REJECT|blocked|denied"Lenguaje del código: JavaScript (javascript)Hay varios comportamientos que deberían llamar la atención durante una revisión. Entre ellos están un servicio desconocido escuchando en un puerto de red, conexiones repetidas hacia un destino que nadie reconoce o tráfico saliente generado por un proceso que normalmente no necesita comunicarse con Internet.
Los intentos repetidos de conexión bloqueados también pueden aportar información. No significan necesariamente que haya una intrusión, pero sí pueden ayudar a reconstruir qué estaba ocurriendo en el sistema.
La clave está en comparar esos eventos con el comportamiento normal del servidor. Una conexión inesperada en un equipo que nunca necesita salir a Internet tiene un significado diferente a la misma conexión en un servidor que mantiene comunicaciones constantes con servicios externos.
Software instalado sin una explicación clara
La instalación de software es otra fuente de pistas. Cuando alguien consigue privilegios administrativos, puede instalar herramientas para reconocimiento de red, movimiento lateral, extracción de datos o minería de criptomonedas.
Entre los programas que pueden aparecer en estos escenarios están herramientas como nmap, netcat o masscan, aunque la presencia de cualquiera de ellas no demuestra por sí misma una actividad maliciosa.
Para revisar actividad relacionada con los gestores de paquetes se puede utilizar:
sudo journalctl --grep="apt|dpkg|dnf|yum|rpm"Lenguaje del código: JavaScript (javascript)También es posible buscar instalaciones ejecutadas mediante sudo:
sudo journalctl _COMM=sudo --grep="install"Lenguaje del código: JavaScript (javascript)Hay varios patrones que merecen atención: software instalado sin una razón conocida, herramientas de seguridad o red que aparecen de repente, paquetes instalados fuera de la ventana habitual de mantenimiento o instalaciones que se producen poco después de un inicio de sesión sospechoso.
También conviene comprobar quién realizó la operación. Una instalación ejecutada por un usuario que normalmente no administra el servidor puede aportar un contexto relevante.
El objetivo no es bloquear automáticamente cualquier herramienta nueva. Los administradores necesitan instalar software con frecuencia. Lo útil es relacionar el cambio con la actividad esperada de la máquina y con otros acontecimientos registrados.
Una cuenta nueva puede convertirse en una puerta trasera
La aparición de una cuenta que nadie esperaba es otra señal que merece una revisión.
Un atacante que ha obtenido acceso puede crear un usuario para conservar una vía de entrada al sistema. Esa cuenta puede recibir una contraseña, una clave SSH o permisos de sudo, lo que permite volver a acceder posteriormente incluso si se corrige el método utilizado para conseguir el primer acceso.
journalctl permite buscar eventos relacionados con la gestión de usuarios:
sudo journalctl --grep="useradd|adduser|new user"Lenguaje del código: JavaScript (javascript)También se puede ampliar la búsqueda a modificaciones y eliminaciones:
sudo journalctl --grep="useradd|usermod|userdel"Lenguaje del código: JavaScript (javascript)Y revisar las operaciones realizadas mediante sudo:
sudo journalctl _COMM=sudo --grep="useradd|adduser|usermod|userdel"Lenguaje del código: JavaScript (javascript)Una cuenta nueva no es necesariamente sospechosa. Puede formar parte de un despliegue, una incorporación de personal o una tarea automática. Lo importante es saber quién la creó, cuándo y con qué permisos.
Una cuenta creada poco después de un acceso anómalo merece mucha más atención que una cuenta generada durante una intervención de mantenimiento documentada.
Cuando los propios logs empiezan a desaparecer
Los registros también pueden convertirse en objetivo. Un atacante que sabe que sus acciones quedan registradas puede intentar eliminar, rotar o modificar los logs para dificultar una investigación posterior.
Una consulta como esta permite revisar actividad del servicio de systemd-journald:
sudo journalctl -u systemd-journald --since "30 days ago"Lenguaje del código: JavaScript (javascript)También se pueden buscar mensajes relacionados con rotación, eliminación, corrupción o cambios de hora:
sudo journalctl --since "30 days ago" \
-g 'Vacuuming|rotate|corrupt|Time has been changed|Suppressed'Lenguaje del código: JavaScript (javascript)La ausencia de registros también puede ser información. Si existe un periodo en el que deberían aparecer acontecimientos y el journal presenta un vacío inesperado, conviene averiguar por qué.
Sin embargo, journalctl tiene limitaciones importantes. No todos los sistemas conservan los registros después de un reinicio y un exceso de mensajes puede provocar que journald suprima algunos eventos.
Por qué journalctl no cuenta toda la historia
Uno de los riesgos de utilizar el journal como única fuente de información es asumir que contiene todo lo que ha sucedido en el servidor.
En algunos sistemas, journald puede utilizar almacenamiento volátil. En ese caso, determinados registros pueden desaparecer después de reiniciar la máquina. Para conservar los journals en disco se puede configurar:
[Journal]
Storage=persistentTambién existe el control de frecuencia de mensajes. Cuando un servicio genera demasiados eventos en poco tiempo, journald puede suprimir parte de ellos. Un mensaje como:
Suppressed 100 messages from sshd.serviceLenguaje del código: JavaScript (javascript)debería considerarse una señal relevante durante una investigación, porque significa que el registro no contiene todos los mensajes generados.
La configuración puede ajustarse mediante RateLimitIntervalSec y RateLimitBurst en journald.conf.
Otro problema es que un atacante que haya conseguido privilegios root puede tener capacidad para rotar, vaciar o eliminar archivos locales del journal. Para detectar modificaciones de registros anteriores existe Forward Secure Sealing, y los logs también pueden enviarse a otro sistema para evitar que toda la evidencia quede almacenada en el mismo servidor comprometido.
La configuración de las claves puede iniciarse con:
sudo journalctl --setup-keysy el sellado puede activarse mediante:
[Journal]
Seal=yesAdemás, herramientas como systemd-journal-remote y rsyslog permiten enviar registros a sistemas separados y construir una infraestructura de logging centralizada.
El otro límite es todavía más importante: journalctl solo muestra los acontecimientos que las aplicaciones, servicios, el kernel u otros componentes han enviado al journal. Sin reglas adicionales de auditoría, pueden quedar fuera actividades como determinados accesos a archivos, llamadas execve o cambios relacionados con setuid.
Por eso una investigación más profunda necesita combinar los logs con herramientas como auditd, inspección de procesos, monitorización de red y sistemas de registro centralizado.
Revisar los logs con frecuencia no evita por sí mismo una intrusión, pero permite disponer de más evidencias cuando algo cambia en un servidor. La utilidad de journalctl está precisamente en convertir esos registros dispersos en una primera línea de investigación, siempre teniendo presente que el journal es una fuente de información y no un registro perfecto de todo lo ocurrido.
Preguntas frecuentes
¿Qué se puede detectar con journalctl?
Puede ayudar a localizar conexiones de red inesperadas, instalaciones de software, creación o modificación de usuarios y acontecimientos relacionados con el propio servicio de registro.
¿Una conexión desconocida significa que el servidor ha sido atacado?
No. Una conexión inesperada es una señal que debe investigarse y compararse con el funcionamiento normal del servidor y con otros registros.
¿Puede un atacante borrar los logs de Linux?
Un usuario con privilegios root puede tener capacidad para rotar, vaciar o eliminar registros locales. Por eso resulta recomendable conservar copias en un sistema de logging separado y utilizar mecanismos que permitan detectar modificaciones.
¿Es suficiente journalctl para investigar un incidente?
No. El journal no registra necesariamente todos los acontecimientos del sistema. Para investigaciones más completas conviene combinarlo con auditd, inspección de procesos, monitorización de red y logging centralizado.
