Auditoría mensual de un VPS cliente: checklist en 45 min

Verificar un estado, no reconstruirlo

Fijar el perímetro antes de la primera auditoría

Para preparar una sola vez, antes de auditar

• Una cuenta de auditoría dedicada — un usuario nominal con sudo limitado a leer registros e inspeccionar la red, en lugar de un root compartido.
• Una lista esperada por VPS — puertos que deben escuchar, cuentas autorizadas, dominios servidos, herramienta de copia y repositorio. Sin referencia, una desviación no se distingue del funcionamiento normal.
• Un script de recogida de solo lectura — encadena los comandos de la checklist y escribe todo en un archivo fechado, para teclear cada comando una sola vez.
• Una carpeta de archivo por cliente — una subcarpeta por mes, conservada fuera del VPS auditado, para poder comparar los meses.
• Una plantilla de informe — el mismo formato para todos los clientes, rellenado a partir de las salidas recogidas.
• Un calendario — un día fijo del mes por cliente, anotado en la agenda del equipo; si no, la auditoría se salta en el primer mes cargado.

Los siete controles, con su presupuesto de tiempo

1. 01

   Actualizaciones pendientes (6 min)

   sudo apt update
apt list --upgradable 2>/dev/null
apt list --upgradable 2>/dev/null | grep -i security
   Aísle los paquetes cuyo origen termina en -security: salen primero. Los demás pasan por validación humana, porque un salto de versión mayor puede romper una aplicación. En AlmaLinux o RHEL, sudo dnf check-update --security cumple el mismo papel. Aun con las actualizaciones automáticas activas, este control muestra lo que sigue bloqueado.

2. 02

   Kernel y reinicio pendiente (4 min)

   uname -r
ls /boot/vmlinuz-*
ls /var/run/reboot-required
sudo needrestart -b -r l
   Si el kernel instalado más reciente difiere de uname -r, o si existe /var/run/reboot-required, hay un reinicio pendiente. En la salida de needrestart, la línea NEEDRESTART-KSTA indica si el kernel cargado está al día, y la lista muestra los servicios que aún usan bibliotecas antiguas. El reinicio nunca se hace en solitario: se planifica con el cliente.

3. 03

   Cuentas y claves SSH (8 min)

   awk -F: '$3>=1000' /etc/passwd
getent group sudo
sudo ssh-keygen -lf /home/<cuenta>/.ssh/authorized_keys
lastlog | grep -v 'Never logged in'
last -n 20
   Cada cuenta humana debe corresponder a una persona conocida del cliente o de la agencia. Cada huella de clave debe pertenecer a alguien que sigue trabajando en el proyecto. Una cuenta sin conexión desde hace meses, o una clave desconocida, pasa a naranja y va al cliente para su validación.

4. 04

   Puertos abiertos (5 min)

   sudo ss -tlnp
sudo ss -ulnp
sudo ufw status verbose
   Compare el resultado con la lista esperada para este VPS. Una base de datos que escucha en todas las interfaces en lugar del bucle local, un puerto de prueba olvidado, un servicio desconocido: cada desviación se anota con el proceso que la abre, sin cerrarla de inmediato, porque un servicio puede depender de ese puerto.

5. 05

   Certificados (4 min)

   openssl s_client -connect su-dominio.com:443 -servername su-dominio.com </dev/null 2>/dev/null | openssl x509 -noout -enddate
   Lea la fecha de caducidad en el servicio realmente expuesto, no solo la presencia de un temporizador de renovación: un temporizador activo puede fallar cada noche. Si el dominio pasa por una CDN, este comando lee el certificado de la CDN. Para el origen, sustituya el host de -connect por la dirección IP del VPS y conserve -servername.

6. 06

   Copias restauradas (10 min)

   restic snapshots
restic restore latest --target /tmp/prueba-restauracion --include /etc/nginx
   Anote la fecha del último punto de restauración, luego restaure de verdad un archivo o una base de datos en un directorio temporal y ábralo. Una copia nunca restaurada no es una prueba, es una hipótesis. Elimine después el directorio temporal. Si el cliente usa otra herramienta, la lógica es la misma: lista de puntos, restauración parcial, comprobación del contenido.

7. 07

   Registros de autenticación (8 min)

   sudo journalctl -u ssh --since '30 days ago' --no-pager | grep -c 'Failed password'
sudo journalctl -u ssh --since '30 days ago' --no-pager | grep 'Accepted'
sudo journalctl _COMM=sudo --since '30 days ago' --no-pager
   Cuente los fallos, liste las conexiones correctas y busque las que vienen de una dirección desconocida. Revise los usos de sudo. En RHEL y derivadas, la unidad se llama sshd, no ssh.

El presupuesto de 45 minutos por VPS

Desplace la tabla

Un script de recogida en lugar de siete sesiones a mano

Archivar y comparar: ahí se ven las derivas

El informe de una página entregado al cliente

1. 08

   La cabecera

   Nombre del cliente, identificador del VPS, dirección IP, fecha de la auditoría, nombre de la persona que la realizó.

2. 09

   La tabla de los siete controles

   Una línea por control con un estado: verde si no hay nada que señalar, naranja si una desviación requiere una decisión del cliente, rojo si se necesita una acción urgente.

3. 10

   Las desviaciones constatadas

   Cada desviación en una frase factual, con la prueba: la línea de salida, el puerto, la cuenta afectada.

4. 11

   Las acciones realizadas

   Lo que la agencia aplicó sola, dentro del perímetro acordado, por ejemplo una actualización de seguridad.

5. 12

   Las acciones que el cliente debe validar

   Reinicio, eliminación de una cuenta, cierre de un puerto, con el riesgo de no hacer nada.

6. 13

   La próxima fecha

   La fecha de la próxima auditoría y, para cada desviación naranja o roja, un plazo límite de tratamiento.

Cuando una salida no dice lo que parece decir

• needrestart no encontrado — el paquete no está instalado por defecto en todas partes. Instálelo una vez con el acuerdo del cliente, o compare a mano uname -r y los kernels presentes en /boot.
• Ningún fallo SSH en los registros — compruebe el nombre de la unidad antes de concluir. Según la distribución, la autenticación se registra bajo ssh, sshd o, en las versiones recientes de OpenSSH, sshd-session. Pruebe sudo journalctl _COMM=sshd-session --since '30 days ago'.
• ss -tlnp no muestra los procesos — sin sudo, la columna de procesos queda vacía para los servicios de otros usuarios.
• Un certificado válido mientras el sitio muestra un error — ha leído el de una CDN o de otro vhost. Apunte a la dirección del VPS y pase el -servername correcto.
• restic pide una contraseña — el repositorio está cifrado. Obtenga el secreto del cliente antes de la auditoría, no durante ella; de lo contrario el control se salta.

La objeción del tiempo: 45 minutos por cliente, cada mes

Cuando la cartera crece

Para ir más lejos

• Montar la base — /blog/linux-hardening-vps-checklist describe el endurecimiento inicial que esta auditoría verifica.
• Automatizar las correcciones — /blog/securite-vps-mises-a-jour-automatiques-debian-ubuntu explica unattended-upgrades, cuyos restos mide el primer control.
• Respaldar bien — /blog/backup-vps-restic-s3-3-2-1 cubre la puesta en marcha de Restic, cuya restauración verifica el sexto control.
• Vigilar de forma continua — /blog/alertes-disque-ram-vps-monitoring-proactif completa la auditoría mensual con alertas entre dos pasadas.
• Inventariar las versiones de PHP — /blog/inventaire-versions-php-parc-sites-clients-agence aplica la misma disciplina al parque de sitios.
• Reaccionar ante una vulnerabilidad — las guías de corrección de la categoría Seguridad y monitorización del blog muestran lo que permite un inventario al día el primer día.

La documentación oficial