Registros y auditoría de accesos en el servidor
Los registros responden a tres preguntas: qué se ha roto, quién ha entrado en el servidor y qué ha hecho. Solo hay respuesta si los registros están activados, se conservan el tiempo suficiente y no están únicamente en el mismo servidor que pudo verse comprometido. Veamos dónde buscarlos en Linux, qué comandos muestran los accesos, cómo configurar la rotación y qué preparar de antemano para que, tras un incidente, haya algo que analizar.
En un Linux con systemd los registros los escriben dos sistemas. El servicio journald de systemd recoge los mensajes de todos los servicios, del kernel y de los inicios de sesión en un diario binario. El servicio rsyslog, si está instalado, reparte esos mismos mensajes en archivos de texto dentro de /var/log. El servidor web, la base de datos y Docker llevan sus propios registros. Dónde está cada cosa hay que saberlo antes del incidente, no durante.
Dónde están los registros
- journald. Se consulta con el comando
journalctl. El diario se guarda en disco si existe el directorio/var/log/journal; si no, solo en memoria, y se pierde al reiniciar (journald.conf, parámetroStorage=auto). Compruébelo en un servidor nuevo:ls /var/log/journal. Si el directorio no existe, créelo y reinicie el servicio:systemctl restart systemd-journald. - Archivos del sistema. En Ubuntu, los inicios de sesión y sudo se escriben en
/var/log/auth.log, y los mensajes generales, en/var/log/syslog. En AlmaLinux y Rocky Linux son/var/log/securey/var/log/messages. En Debian 12 y posteriores rsyslog no se instala por defecto, y todo está solo en journald. - Servidor web. nginx escribe en
/var/log/nginx/access.logyerror.log; Apache, en/var/log/apache2/en Debian y Ubuntu o en/var/log/httpd/en AlmaLinux. El registro de acceso muestra cada solicitud: dirección, hora, ruta, código de respuesta, tamaño y navegador. Los campos se definen con la directiva log_format; si la web está detrás de una CDN, configure la transmisión de la dirección real del visitante, o en el registro solo aparecerán las direcciones de la CDN (más detalles en el artículo CDN: cuándo la necesita una web). - Aplicaciones y Docker. Las bases de datos escriben en sus propios directorios dentro de
/var/log, y los contenedores, en archivos de Docker que se leen condocker logs.
Unos cuantos comandos de journalctl bastan en la mayoría de los casos: journalctl -u nginx --since "1 hour ago" muestra los mensajes de un servicio en la última hora; journalctl -p err -b, los errores desde el último arranque; journalctl -f, el flujo de mensajes nuevos; journalctl --disk-usage, cuánto espacio ocupa el diario.
Quién ha entrado en el servidor
Cada acceso por SSH deja una entrada con el nombre de usuario, la dirección y el método de autenticación: clave o contraseña. Los accesos correctos se ven así:
- en journald:
journalctl -u ssh --since today | grep Accepted(en AlmaLinux el servicio se llamasshd); - en archivo:
grep Accepted /var/log/auth.logo/var/log/secure; - como resumen: el comando
lastmuestra los accesos y los reinicios, ylastb, los intentos fallidos.
En Debian 13 ya no existen los comandos last, lastb y lastlog: sus archivos antiguos no pueden guardar fechas posteriores a 2038. En su lugar se proponen los paquetes wtmpdb y lastlog2 (notas de la versión de Debian 13). Las entradas Accepted del diario siguen ahí en cualquier versión.
Qué revisar. Accesos desde direcciones desconocidas y a horas inusuales. Accesos con contraseña si configuró el acceso solo con clave: significa que el ajuste no se aplicó. Comandos ejecutados con sudo: en auth.log y en journald consta para cada uno quién lo ejecutó y qué. Claves nuevas en ~/.ssh/authorized_keys y usuarios nuevos en /etc/passwd: se añaden para volver al servidor más adelante. Si necesita una auditoría detallada de cambios en archivos y comandos, Linux tiene el subsistema de auditoría auditd, pero sus reglas requieren una configuración aparte y espacio en disco.
fail2ban: qué aporta además de SSH
fail2ban lee los registros y bloquea temporalmente las direcciones que fallan una y otra vez al iniciar sesión. La instalación y la protección de SSH se describen en el artículo Primeros 10 pasos tras comprar un VPS: seguridad. Por defecto, una dirección se bloquea durante 10 minutos tras 5 fallos en 10 minutos (jail.conf). Qué conviene añadir:
- Bloqueos largos para reincidentes. La regla
recidivelee el registro del propio fail2ban y bloquea durante una semana la dirección que ha caído varias veces en un día. El parámetrobantime.increment = trueduplica la duración con cada nuevo bloqueo. - Reglas para el servidor web. Las reglas predefinidas
nginx-http-auth,nginx-limit-reqynginx-botsearchreaccionan a contraseñas erróneas en páginas protegidas, a superar el límite de frecuencia de solicitudes y al rastreo de direcciones inexistentes. - Sus propias direcciones como excepción. El parámetro
ignoreipcon la dirección estática de la oficina evita que se bloquee a sí mismo.
fail2ban no protege de ataques distribuidos desde miles de direcciones ni sustituye el acceso con clave. Su principal ventaja para la auditoría es un registro más corto: quedan los eventos con sentido, no decenas de miles de intentos idénticos de adivinar la contraseña. La lista de direcciones bloqueadas la muestra fail2ban-client status sshd.
Rotación y espacio en disco
Los registros crecen sin parar, y en los VPS económicos el disco es pequeño. Según el catálogo de accsly.io a noviembre de 2026, los planes VPS con 1 GB de memoria tienen un disco mediano de 20 GB, y el 9 % de los planes VPS tiene 20 GB de disco o menos. El registro de acceso de una web con mucho tráfico, o un contenedor que escribe un error en bucle, llenan un disco así en días, y entonces dejan de funcionar la base de datos y la propia web.
- journald ocupa por defecto como máximo el 10 % del sistema de archivos y no más de 4 GB. Puede fijar su propio límite con el parámetro
SystemMaxUse=en/etc/systemd/journald.conf, y el plazo de conservación conMaxRetentionSec=, que por defecto está desactivado. Para liberar espacio de una vez:journalctl --vacuum-size=500Mo--vacuum-time=30d. - Los archivos de texto los rota logrotate según las reglas de
/etc/logrotate.d/. En Ubuntu 24.04 los registros del sistema se rotan una vez por semana y se conservan 4 archivos antiguos, es decir, alrededor de un mes. Los registros de nginx del paquete de AlmaLinux 9, una vez al día, con 10 archivos antiguos. Los parámetrosrotate,dailyoweekly,compressymaxsizecambian el plazo, la compresión y la rotación por tamaño. El modocopytruncatesirve para programas que no saben reabrir el archivo, pero según la documentación puede perder líneas. Para comprobar una regla sin aplicar cambios:logrotate -d /etc/logrotate.d/nginx. - Docker escribe por defecto los registros de los contenedores sin límite de tamaño (controlador json-file). Defina
max-sizeymax-fileen/etc/docker/daemon.jsony vuelva a crear los contenedores: los ajustes solo se aplican a los nuevos. Más detalles en el artículo Docker en un VPS: por dónde empezar.
Para encontrar qué ha llenado el disco, df -h muestra la partición llena y du -xh /var/log | sort -h | tail, los directorios más grandes. No borre un archivo de registro que un servicio mantiene abierto: el espacio no se libera hasta que el servicio se reinicie. Vacíelo con el comando truncate -s 0. Es mejor recibir el aviso de disco lleno con antelación; de eso trata el artículo Monitorización de un servidor: disponibilidad, carga y alertas.
Cómo conservar los registros para analizar un incidente
Si el servidor ha sido comprometido, lo primero que hace el atacante con permisos de root es modificar o borrar los registros. Por eso una copia que sale del servidor en el momento vale más que cualquier ajuste de conservación en el propio servidor.
- Envíe los registros a otro servidor. rsyslog puede reenviar mensajes por la red, y journald tiene para ello el servicio systemd-journal-upload. El servidor receptor puede ser un VPS económico aparte con un disco mayor o un sistema de recopilación de registros como Loki, Graylog u OpenSearch; los planes adecuados están en la selección VPS para Elasticsearch.
- Decida cuánto tiempo conservarlos. Para analizar la mayoría de los incidentes hacen falta registros de 30 a 90 días: una intrusión a menudo no se descubre el mismo día en que se produce. En el propio servidor basta con una o dos semanas; el resto, en el servidor de recopilación o en un archivo.
- Sincronice la hora. Sin una hora exacta no se pueden relacionar los eventos de distintos servidores. Compruebe
timedatectl: la línea «System clock synchronized» debe mostrar yes. - No guarde en los registros lo que sobra. Contraseñas, tokens y números completos de tarjeta no deben llegar al registro. Las direcciones IP y los nombres de usuario son datos personales según el RGPD y muchas leyes locales de protección de datos, así que conviene fijar el plazo de conservación en la política de tratamiento de datos; más detalles en el artículo El RGPD y la elección del hosting.
- Ante un incidente, primero conserve y después repare. Copie los registros y haga una instantánea del disco en el proveedor antes de reinstalar el sistema. Cómo funcionan las instantáneas y las copias de seguridad se explica en el artículo Copias de seguridad de un VPS: estrategias y herramientas.
Si los registros se necesitan no solo para el análisis, sino también para alertas (un pico de errores 500 o un acceso como root), se recopilan junto con las métricas en un servidor de monitorización aparte. Los planes para esa tarea están en la selección VPS para monitorización.