Endurecimiento de Ubuntu 24.04 en 30 minutos: lista de verificación para un VPS nuevo

Qué configuramos y por qué

Un nuevo VPS con Ubuntu 24.04 suele estar disponible mediante una dirección IPv4 pública inmediatamente después del aprovisionamiento. Los escáneres de Internet encuentran esa dirección en cuestión de minutos: verifican SSH, puertos web, bases de datos, Docker API, paneles de control y servicios con vulnerabilidades conocidas. Incluso un servidor sin sitio web ni aplicaciones empieza a recibir intentos de fuerza bruta de contraseñas casi de inmediato.

El objetivo de esta guía es crear una capa básica segura para Ubuntu 24.04 LTS. No sustituye una auditoría de una aplicación concreta, la protección del código, la configuración de IAM ni la protección DDoS, pero cubre los errores típicos de un VPS nuevo: acceso root por contraseña, puertos innecesarios abiertos, falta de actualizaciones, intentos de inicio de sesión ilimitados y ausencia de copias de seguridad.

Después de completar la lista de verificación, el servidor contará con un administrador independiente, acceso mediante claves SSH, un firewall restringido, Fail2ban, actualizaciones automáticas de seguridad activadas, auditoría de puertos abiertos y una base para copias de seguridad cifradas. Este conjunto es adecuado para VPS con un sitio web, API, VPN, servicio Git, servidor de Minecraft, bot, Docker Compose y herramientas internas.

Qué no incluye el hardening básico

El hardening del SO no hace segura una aplicación insegura. Si publica WordPress, GitLab, Nextcloud, Grafana, Mattermost o su propia API, debe actualizar la aplicación por separado, utilizar contraseñas seguras y MFA, desactivar endpoints de prueba, restringir las URL administrativas y revisar los registros periódicamente.

Tampoco debe considerar el cambio del puerto SSH como una medida de protección. Un puerto no estándar reduce el ruido en los registros, pero no sustituye las claves, el firewall ni la prohibición de contraseñas. Los escáneres encuentran rápidamente los puertos abiertos.

Regla de orden seguro: primero añada y pruebe el nuevo acceso; después endurezca el anterior. No cierre la sesión SSH actual hasta comprobar que la nueva sesión funciona.

Cloud-managed y self-hosted: qué elegir

Se elige un VPS self-hosted por el control: puede ejecutar las versiones de software necesarias, mantener los datos en la jurisdicción elegida, no pagar por cada componente managed y no depender de las limitaciones de la plataforma. El precio del control es la necesidad de realizar operaciones periódicas. Esta lista de verificación reduce el riesgo inicial, pero debe repetirse tras cambios en la infraestructura.

Qué configuración de VPS se necesita para esta tarea

El hardening en sí casi no requiere recursos. Ubuntu 24.04, OpenSSH, UFW, Fail2ban y unattended-upgrades funcionan correctamente en un servidor pequeño. Los recursos no los determina la protección, sino su futura aplicación: base de datos, contenedores Docker, servidor de juegos, VPN, CI, almacenamiento de archivos o aplicación web.

Para un nuevo servidor versátil destinado a un proyecto pequeño, un inicio razonable es 2 vCPU, 4 GB de RAM, 60–80 GB NVMe e IPv4 público. Este margen permite utilizar Docker, reverse proxy, registros, swap y una base de datos pequeña sin presión constante sobre la memoria. Como una de las opciones neutrales, puede elegir un VPS con las características indicadas, pero antes de contratarlo compare el espacio en disco con el tamaño de las copias de seguridad y el crecimiento de los datos.

Cuándo basta un VPS

Un VPS es adecuado para casi todos los servicios individuales y equipos pequeños. El aislamiento de la máquina virtual, los snapshots periódicos y la posibilidad de aumentar rápidamente el plan son convenientes para empezar. Para WireGuard, una aplicación web, monitorización, un par de contenedores y varias decenas de usuarios, un VPS suele ser más que suficiente.

Cuándo se necesita un dedicated

Elija un dedicated si necesita CPU garantizada sin competencia con vecinos, I/O muy intensivo, mucha memoria, grandes conjuntos de datos locales, alto rendimiento de red o un rendimiento predecible bajo carga constante. Ejemplos típicos: un servidor de juegos grande, un indexador de blockchain, runners de CI, varias máquinas virtuales pesadas, transcodificación multimedia y una base de datos con cientos de gigabytes.

Cómo influye la ubicación

La ubicación influye en la latencia, la legislación sobre datos y la velocidad hacia su audiencia. Para VPN, elija una región cercana a los usuarios. Para una base de datos con datos personales, tenga en cuenta los requisitos de su jurisdicción y contratos. Para la administración, no solo importa la geografía, sino también la estabilidad de la ruta: compruebe la latencia con el comando ping y la velocidad real después del lanzamiento.

Preparación del servidor

A continuación se supone que el proveedor ha proporcionado una dirección IPv4 y una contraseña root temporal, o ha añadido su clave pública. Trabaje desde una terminal local normal. En Windows sirven PowerShell, Windows Terminal o WSL. Todos los comandos se ejecutan en el servidor, salvo que se indique lo contrario.

Compruebe el sistema y actualice los paquetes

Ubuntu 24.04 LTS utiliza la rama Linux 6.8 con actualizaciones HWE según la imagen. No se guíe únicamente por el número de versión: los parches de seguridad suelen incorporarse mediante backport, por lo que un paquete puede tener un número upstream antiguo y aun así estar corregido.

# Подключитесь к серверу по адресу, выданному после провижининга.
ssh root@SERVER_IP

# Проверьте релиз Ubuntu, ядро и текущего пользователя.
cat /etc/os-release
uname -r
whoami

# Обновите индекс пакетов и установленные пакеты.
apt update && apt full-upgrade -y

# Перезагрузите сервер, если обновилось ядро или systemd.
reboot

Después de reiniciar, conéctese de nuevo. Si SSH no responde temporalmente, espere uno o dos minutos y compruebe la consola web del proveedor. No continúe la configuración hasta asegurarse de que el sistema se ha iniciado.

Cree un administrador independiente

No utilice root como cuenta diaria. Un usuario independiente proporciona una auditoría clara de las acciones, reduce el riesgo de ejecutar accidentalmente un comando con privilegios completos y permite desactivar de forma segura el inicio de sesión root por SSH.

# Создайте пользователя admin и добавьте его в группу sudo.
adduser admin
usermod -aG sudo admin

# Создайте каталог для SSH-ключей с корректными правами.
install -d -m 700 -o admin -g admin /home/admin/.ssh

# Скопируйте уже работающий root authorized_keys новому пользователю.
cp /root/.ssh/authorized_keys /home/admin/.ssh/authorized_keys
chown admin:admin /home/admin/.ssh/authorized_keys
chmod 600 /home/admin/.ssh/authorized_keys

Si root no tiene el archivo authorized_keys, cree una clave en su ordenador. Para 2026, una elección práctica es Ed25519. No transfiera la clave privada al servidor ni la envíe mediante mensajería.

# Выполните на локальном компьютере: создайте ключ Ed25519.
ssh-keygen -t ed25519 -a 100 -C "admin@my-vps"

# Скопируйте публичный ключ на сервер; команда спросит текущий пароль root.
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@SERVER_IP

# На сервере повторите копирование ключа в учётную запись admin.
install -d -m 700 -o admin -g admin /home/admin/.ssh
cp /root/.ssh/authorized_keys /home/admin/.ssh/authorized_keys
chown admin:admin /home/admin/.ssh/authorized_keys
chmod 600 /home/admin/.ssh/authorized_keys

Abra una segunda terminal y compruebe el nuevo acceso. No cierre la antigua sesión root.

# Выполните локально: вход должен пройти по ключу без пароля пользователя.
ssh -i ~/.ssh/id_ed25519 admin@SERVER_IP

# Проверьте, что sudo работает в новой сессии.
sudo whoami

El resultado esperado del último comando es root. Solo después de esto, continúe con la configuración de SSH. Si la clave no funciona, corrija primero los permisos de /home/admin/.ssh y authorized_keys.

Instalación de software — paso a paso

Ubuntu 24.04 utiliza los paquetes OpenSSH 9.6p1 con parches de Ubuntu, UFW 0.36.x, Fail2ban 1.0.x y unattended-upgrades 2.9.x. Compruebe siempre la versión exacta instalada mediante apt-cache policy: la seguridad depende de las actualizaciones disponibles en el repositorio específico, no solo del número de versión upstream.

# Conéctese como el nuevo usuario e instale las herramientas básicas.
ssh admin@SERVER_IP
sudo apt update
sudo apt install -y ufw fail2ban unattended-upgrades apt-listchanges \
  curl ca-certificates gnupg jq vim-tiny lsof needrestart chrony

El paquete needrestart informa qué servicios requieren reiniciarse después de actualizar bibliotecas. chrony mantiene la hora precisa, lo cual es importante para TLS, tokens, registros e investigación de incidentes.

# Compruebe las versiones y el estado de los servicios principales tras la instalación.
apt-cache policy openssh-server ufw fail2ban unattended-upgrades
systemctl status ssh --no-pager
systemctl status chrony --no-pager
timedatectl status

Configure UFW antes de desactivar los métodos SSH débiles

UFW administra las reglas de Netfilter. La secuencia segura es: permitir SSH, activar el firewall, comprobar el estado y después abrir solo los servicios necesarios. Si utiliza un puerto SSH no estándar, permita ese puerto antes de aplicar la configuración.

# Establezca la política: conexiones entrantes denegadas, salientes permitidas.
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Permita SSH y active el firewall.
sudo ufw allow 22/tcp comment 'OpenSSH'
sudo ufw enable

# Compruebe las reglas activas y sus números.
sudo ufw status numbered

Si el servidor alojará un sitio HTTPS normal, abra HTTP y HTTPS. El puerto 80 es necesario para que Caddy o Certbot emitan un certificado mediante HTTP-01. Tras obtener el certificado, normalmente se deja abierto para la renovación automática y la redirección a HTTPS.

# Abra los puertos web solo si el servidor realmente alojará un servicio HTTP/HTTPS.
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Asegúrese de que solo esté disponible el conjunto de puertos esperado.
sudo ufw status verbose
sudo ss -tulpn

Instale y active las actualizaciones automáticas de seguridad

La aplicación automática de actualizaciones de seguridad no sustituye las actualizaciones manuales. Cierra el intervalo crítico entre la publicación de un parche y su ventana de mantenimiento programada. Para servicios de producción sensibles a reinicios, pruebe las actualizaciones previamente en un servidor de staging.

# Inicie la configuración interactiva de las actualizaciones automáticas de Ubuntu.
sudo dpkg-reconfigure --priority=low unattended-upgrades

# Active los temporizadores de descarga de listas de paquetes e instalación de actualizaciones.
sudo systemctl enable --now apt-daily.timer apt-daily-upgrade.timer

# Compruebe la programación de los temporizadores del sistema.
systemctl list-timers --all | grep -E 'apt-daily|unattended'

Active Fail2ban

Fail2ban lee los registros y bloquea temporalmente direcciones IP después de una serie de intentos fallidos. Es útil contra ataques masivos de fuerza bruta, pero no sustituye las claves SSH. En Ubuntu 24.04, el registro SSH suele estar disponible mediante systemd journal; a continuación se utiliza el backend systemd.

# Cree el directorio de configuración local de Fail2ban.
sudo install -d -m 755 /etc/fail2ban/jail.d

# Cree una configuración local independiente para SSH.
sudo tee /etc/fail2ban/jail.d/sshd.local > /dev/null <<'EOF'
[sshd]
enabled = true
backend = systemd
port = ssh
maxretry = 5
findtime = 10m
bantime = 1h
banaction = ufw
EOF

# Compruebe la configuración e inicie el servicio.
sudo fail2ban-client -d > /dev/null
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

No edite sin necesidad los archivos /etc/fail2ban/jail.conf y /etc/ssh/sshd_config proporcionados por el paquete: las actualizaciones pueden modificarlos. Para configuraciones locales, utilice jail.d/.local y sshd_config.d/.conf.

Configuración

Refuerce SSH sin perder el acceso

Ubuntu 24.04 admite el directorio /etc/ssh/sshd_config.d/. Crearemos un archivo con un conjunto prioritario de parámetros locales. Antes de reiniciar, ejecute siempre una comprobación de sintaxis: un solo error en la configuración de SSH puede dejar el servidor sin acceso remoto.

# Cree un archivo local con configuraciones seguras de OpenSSH.
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
UsePAM yes
X11Forwarding no
AllowUsers admin
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE
EOF

# Compruebe la sintaxis y aplique los cambios sin un reinicio completo.
sudo sshd -t
sudo systemctl reload ssh

# Compruebe los parámetros efectivos, teniendo en cuenta todos los archivos include.
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication|allowusers|maxauthtries'

Ahora abra otra conexión SSH nueva como admin. Si la conexión funciona, el acceso root mediante SSH se ha desactivado correctamente. Si utiliza varios administradores, enumérelos en AllowUsers separados por espacios o elimine esta línea y gestione el acceso de otras formas.

# Ejecute localmente: compruebe el inicio de sesión del administrador tras el hardening de SSH.
ssh -o PreferredAuthentications=publickey admin@SERVER_IP

# Ejecute localmente: el inicio de sesión root debe ser rechazado.
ssh root@SERVER_IP

Añada parámetros del kernel mediante sysctl

Los siguientes parámetros desactivan el enrutamiento IPv4 no utilizado y reducen el riesgo de diversas suplantaciones de red. No los aplique a ciegas en un VPS que funcione como router, gateway WireGuard, nodo Kubernetes o gateway NAT: en esos casos se requerirá una configuración de red independiente.

# Cree configuraciones sysctl seguras para un servidor público convencional.
sudo tee /etc/sysctl.d/99-hardening.conf > /dev/null <<'EOF'
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_syncookies = 1
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
EOF

# Aplique los archivos sysctl y compruebe uno de los parámetros.
sudo sysctl --system
sysctl net.ipv4.tcp_syncookies

Guarde los secretos fuera del código y del repositorio

Las contraseñas de bases de datos, los tokens API, las claves S3 y las credenciales SMTP no deben llegar a Git, Dockerfile, shell history ni a configuraciones públicas de Nginx/Caddy. Para un servicio pequeño, guarde las variables en un archivo .env con permisos 600. Para systemd, utilice EnvironmentFile. En una infraestructura mayor, utilice Vault, SOPS, cloud secret manager o un almacén de secretos equivalente.

# Cree un directorio protegido y un archivo de variables de entorno para la aplicación.
sudo install -d -m 750 -o root -g root /etc/myapp
sudo tee /etc/myapp/app.env > /dev/null <<'EOF'
APP_ENV=production
DATABASE_URL=postgresql://app:[email protected]:5432/app
JWT_SECRET=CHANGE_ME_TO_A_LONG_RANDOM_VALUE
EOF
sudo chmod 600 /etc/myapp/app.env

# Genere un secreto criptográficamente aleatorio y reemplace el placeholder manualmente.
openssl rand -base64 48

TLS/HTTPS mediante Caddy

Si hay un servicio web en el VPS, publíquelo mediante un reverse proxy. Caddy obtiene y renueva automáticamente los certificados TLS si el registro DNS del dominio apunta a la IP del servidor y los puertos 80 y 443 son accesibles desde el exterior. No instale Caddy solo por hardening: si no hay servicio web, mantenga cerrados los puertos 80 y 443.

# Añada el repositorio oficial de Caddy para la rama estable 2.x actual.
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | \
  sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | \
  sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install -y caddy

# Compruebe la versión instalada de Caddy.
caddy version

Supongamos que la aplicación escucha solo en la dirección local 127.0.0.1:3000. Esta es una restricción importante: el servicio no debe abrir adicionalmente el puerto 3000 a Internet. Sustituya el dominio y el puerto por sus propios valores.

example.com {
    encode zstd gzip

    reverse_proxy 127.0.0.1:3000

    header {
        -Server
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "strict-origin-when-cross-origin"
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
    }

    log {
        output file /var/log/caddy/example.com.access.log
        format json
    }
}

# Guarde el Caddyfile, compruébelo y recargue Caddy.
sudo cp /etc/caddy/Caddyfile /etc/caddy/Caddyfile.bak
sudo vim /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl enable --now caddy
sudo systemctl reload caddy

# Compruebe la redirección HTTP, HTTPS y el endpoint health local de la aplicación.
curl -I http://example.com
curl -I https://example.com
curl -fsS http://127.0.0.1:3000/health || echo "Compruebe el endpoint de la aplicación"

Comprobación final de la superficie de ataque

Compruebe no solo lo que ha configurado, sino también lo que realmente está escuchando en la red. El comando ss muestra los sockets locales. Los puertos vinculados a 127.0.0.1 no son accesibles directamente desde Internet; las direcciones 0.0.0.0 y [::] son accesibles en todas las interfaces si el firewall lo permite.

# Muestre todos los puertos TCP/UDP en escucha y los procesos propietarios.
sudo ss -tulpn

# Compruebe el firewall, Fail2ban, las actualizaciones y la necesidad de reiniciar.
sudo ufw status numbered
sudo fail2ban-client status sshd
sudo unattended-upgrade --dry-run --debug
sudo needrestart -r l

# Compruebe la disponibilidad del servidor y TLS desde el equipo local.
ping -c 4 SERVER_IP
curl -fsSI https://example.com

Para una comprobación externa, utilice un segundo servidor o Internet móvil: asegúrese de que solo estén abiertos los puertos 22, 80 y 443, si ese es su plan. No abra PostgreSQL en 5432, MySQL en 3306, Redis en 6379, Docker API en 2375 ni paneles de administración «temporalmente»: estas soluciones temporales a menudo permanecen para siempre.

Copias de seguridad y mantenimiento

Una instantánea de VPS es útil, pero no debe ser la única copia de seguridad. Puede encontrarse en la misma cuenta, la misma ubicación e incluso en la misma infraestructura que el servidor original. Un esquema eficaz es la regla 3-2-1: al menos tres copias de los datos, en dos tipos de almacenamiento, con una copia fuera del servidor principal.

Qué se debe respaldar

• Configuración: /etc, Caddyfile, systemd units, archivos Docker Compose, configuraciones de firewall y scripts.
• Datos de aplicaciones: directorios uploads, volumes de Docker, archivos de usuarios, contenido multimedia, claves y certificados cuando sea necesario.
• Bases de datos: dump lógico de PostgreSQL o MySQL más una comprobación de restauración.
• Secretos: archivos env cifrados, claves de acceso, recovery codes. No guarde secretos en un archivo normal sin cifrar.
• Documentación: lista de dominios, usuarios, puertos, procedimiento de restauración y fecha de la última prueba de restore.

Para un servidor pequeño, Restic 0.17.x o posterior es práctico: cifra los datos en el VPS, admite almacenamientos compatibles con S3, deduplicación y políticas de retención. Un repositorio Restic no reemplaza una contraseña: perder la contraseña del repositorio sin un almacenamiento seguro independiente implica perder el acceso a las copias.

# Установите Restic и создайте каталог для защищённых переменных бэкапа.
sudo apt install -y restic
sudo install -d -m 700 /root/.config/restic

# Создайте файл окружения; замените все значения на реальные.
sudo tee /root/.config/restic/backup.env > /dev/null <<'EOF'
export RESTIC_REPOSITORY="s3:https://s3.example.net/my-vps-backup"
export RESTIC_PASSWORD="CHANGE_ME_TO_A_LONG_UNIQUE_PASSWORD"
export AWS_ACCESS_KEY_ID="CHANGE_ME"
export AWS_SECRET_ACCESS_KEY="CHANGE_ME"
EOF
sudo chmod 600 /root/.config/restic/backup.env

# Инициализируйте новый зашифрованный репозиторий только один раз.
sudo bash -c 'source /root/.config/restic/backup.env && restic init'

Para PostgreSQL, cree primero un dump y después archívelo con Restic. El siguiente comando está pensado para una base de datos local y un usuario con permisos de lectura sobre todos los objetos necesarios. Para un contenedor Docker de base de datos, use docker exec o el mecanismo oficial de dump dentro del contenedor.

# Создайте каталог для дампов, недоступный обычным пользователям.
sudo install -d -m 700 /var/backups/postgresql

# Пример: создайте сжатый дамп базы appdb от имени системного пользователя postgres.
sudo -u postgres pg_dump -Fc appdb > /var/backups/postgresql/appdb.dump
sudo chmod 600 /var/backups/postgresql/appdb.dump

# Создайте ежедневный скрипт: дамп БД, backup Restic, проверка и политика хранения.
sudo tee /usr/local/sbin/backup-server.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

source /root/.config/restic/backup.env

DATE="$(date +%F)"
BACKUP_PATHS=(
  /etc
  /home
  /opt
  /srv
  /var/lib/docker/volumes
  /var/backups/postgresql
)

restic backup "${BACKUP_PATHS[@]}" \
  --exclude-caches \
  --exclude='/home//.cache' \
  --tag "server" \
  --tag "$DATE"

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=1/50
EOF
sudo chmod 700 /usr/local/sbin/backup-server.sh

# Запустите первый бэкап вручную и убедитесь, что он завершается без ошибок.
sudo /usr/local/sbin/backup-server.sh
sudo bash -c 'source /root/.config/restic/backup.env && restic snapshots'

# Добавьте запуск каждый день в 03:20 и запись лога в отдельный файл.
sudo tee /etc/cron.d/server-backup > /dev/null <<'EOF'
20 3    root /usr/local/sbin/backup-server.sh >> /var/log/server-backup.log 2>&1
EOF

# Проверьте, что cron видит задание, и посмотрите последние строки лога после запуска.
sudo systemctl status cron --no-pager
sudo tail -n 50 /var/log/server-backup.log

Comprobación de la restauración

Una copia de seguridad se considera funcional solo después de restaurarla. Una vez al mes, restaure un archivo y un dump de base de datos de prueba en un directorio independiente o en otro servidor. No restaure una base de datos sobre datos de producción sin detener la aplicación y contar con un plan de reversión confirmado.

# Просмотрите содержимое последнего snapshot и восстановите его в тестовый каталог.
sudo bash -c 'source /root/.config/restic/backup.env && restic snapshots'
sudo mkdir -p /tmp/restic-restore
sudo bash -c 'source /root/.config/restic/backup.env && restic restore latest --target /tmp/restic-restore'

# Убедитесь, что нужные файлы и дамп действительно восстановились.
sudo find /tmp/restic-restore -maxdepth 4 -type f | head -n 30

Plan de actualizaciones

Las actualizaciones de seguridad pueden aplicarse automáticamente, pero las actualizaciones de la aplicación, las imágenes Docker y las versiones principales de la base de datos se planifican mejor en una maintenance window. Para una aplicación web stateless, utilice una actualización rolling: inicie la nueva versión, compruebe el healthcheck y luego cambie el reverse proxy. Para una base de datos única, normalmente se requiere una breve interrupción controlada.

1. Una vez por semana, revise journalctl -p warning..alert, el estado del disco y los registros de backup.
2. Una vez al mes, ejecute sudo apt update && sudo apt full-upgrade y reinicie si es necesario.
3. Una vez al mes, compruebe la restauración de al menos un archivo y un dump de base de datos.
4. Una vez por trimestre, revise los usuarios, las claves SSH, los puertos abiertos y los tokens de acceso.

Solución de problemas + FAQ

Después de configurar SSH recibo Permission denied (publickey)

Primero, no cierre la sesión anterior o utilice la consola web. Compruebe que inicia sesión con el usuario correcto: ssh admin@SERVER_IP. En el servidor, compruebe los permisos: el directorio ~/.ssh debe tener modo 700, y authorized_keys, 600 y pertenecer al usuario. Consulte la causa en sudo journalctl -u ssh -n 100. Un error frecuente es copiar la clave a root mientras ya está habilitado PermitRootLogin no en la configuración.

UFW está habilitado, pero el sitio o SSH no es accesible

Conéctese mediante la consola y ejecute sudo ufw status numbered y sudo ss -tulpn. El firewall puede permitir el puerto, pero la aplicación no lo está escuchando o está vinculada solo a 127.0.0.1. Para SSH debe existir una regla allow para el puerto real. Para el sitio, compruebe las reglas 80/tcp y 443/tcp, el registro DNS del dominio y el estado de Caddy. Si hay un error, la regla se puede eliminar por número mediante sudo ufw delete НОМЕР.

Fail2ban no bloquea direcciones o no detecta intentos de SSH

Compruebe el servicio con sudo systemctl status fail2ban y, a continuación, ejecute sudo fail2ban-client status sshd. En Ubuntu 24.04, el backend correcto para SSH suele ser systemd, por eso se indica en el archivo jail local. Consulte los registros mediante sudo journalctl -u fail2ban -n 100. Asegúrese de que la configuración especifique banaction = ufw si UFW se utiliza como firewall.

Las actualizaciones automáticas están habilitadas, pero el servidor solicita reinicio

Es una situación normal después de actualizar el kernel, algunas bibliotecas o systemd. Compruebe la existencia del archivo /var/run/reboot-required y la salida de sudo needrestart -r l. Elija una ventana de mantenimiento, avise a los usuarios y ejecute sudo reboot. Las actualizaciones de seguridad automáticas reducen la ventana de vulnerabilidad, pero no pueden reiniciar de forma segura todas las aplicaciones sin considerar su carga y dependencias.

¿Qué configuración de VPS es mínimamente adecuada?

Para el hardening en sí, bastan 1 vCPU, 1 GB de RAM y 20 GB de SSD si el servidor actúa como bastion-host, VPN sencilla o bot pequeño. Para un inicio práctico y versátil, es mejor contar con 2 vCPU, 2–4 GB de RAM y 40–80 GB de NVMe: habrá espacio para Docker, registros, actualizaciones y dumps de respaldo. No calcule el disco solo para el SO: reserve con antelación espacio para datos, archivos temporales y copias locales antes de subirlas a un backup externo.

¿Qué elegir: VPS o dedicated para esta tarea?

Para hardening, un sitio pequeño, VPN, API y varios contenedores, un VPS es suficiente. Es más económico, se despliega más rápido y es más fácil de escalar en memoria o disco. Se necesita un dedicated no por el hardening de Ubuntu en sí, sino con una carga pesada constante: alto I/O de base de datos, servidor de juegos grande, transcodificación, CI o requisitos de rendimiento de CPU garantizado. En ambos casos, las reglas de SSH, firewall, actualizaciones y copias de seguridad siguen siendo responsabilidad del administrador.

Caddy no obtiene un certificado TLS y muestra un error ACME

Compruebe que el registro A del dominio apunta al IPv4 público del VPS y que el registro AAAA es correcto o no existe. Los puertos 80 y 443 deben estar abiertos en UFW y en el firewall externo del proveedor. Ejecute sudo journalctl -u caddy -n 100 --no-pager. A menudo el problema es que otro servidor web ya ocupa el puerto 80 o que el dominio apunta a una IP antigua. Tras corregirlo, Caddy volverá a intentarlo automáticamente.

¿Cómo saber si Docker expuso accidentalmente una base de datos o panel a Internet?

Ejecute sudo ss -tulpn y compruebe las direcciones de vinculación. Son peligrosos los servicios en 0.0.0.0:5432, 0.0.0.0:3306, 0.0.0.0:6379 y puertos similares. En Docker Compose, publique los servicios internos como 127.0.0.1:5432:5432 o no utilice en absoluto la sección ports si los contenedores se comunican por la red interna. Deje expuestos únicamente el reverse proxy en 80/443 y SSH en el puerto elegido.

Conclusiones y próximos pasos

Ahora el nuevo VPS con Ubuntu 24.04 cuenta con protección básica: sistema actualizado, acceso SSH mediante claves, prohibición de inicio de sesión como root, UFW, Fail2ban, configuraciones sysctl, TLS para el servicio web y un backup externo cifrado. Esto reduce notablemente el riesgo de ataques automatizados típicos y errores de configuración inicial.

Como siguiente paso, añada monitorización de recursos y disponibilidad, por ejemplo, comprobación de disco, memoria, caducidad de certificados TLS y estado de la tarea de backup. Después, configure políticas de hardening independientes para su aplicación: Docker, PostgreSQL, WireGuard, framework web o panel de control.

Después de cada servicio nuevo, repita una auditoría breve: si necesita un puerto público, quién tiene acceso, dónde se almacenan los secretos, cómo se realiza la actualización y si los datos pueden restaurarse desde un backup. Este ciclo es precisamente lo que convierte una configuración puntual de VPS en una infraestructura mantenible.