Seguridad Linux VPS: Capas, Amenazas, Hardening

Acabas de provisionar un Linux VPS. En 90 segundos, los escáneres automáticos ya lo han encontrado. En la primera hora, tus logs de SSH mostrarán cientos de intentos de login por fuerza bruta desde botnets que prueban usuarios y contraseñas comunes.

Esto no es hipotético. Le pasa a cualquier servidor con IP pública.

La mayoría de las guías de seguridad para VPS te dan una lista numerada de 20+ consejos sin estructura ni prioridad. Esta guía toma un enfoque diferente. Mapea la seguridad como capas concéntricas, cada una reduciendo tu superficie de ataque. Entenderás qué ataques impactan realmente tu servidor y qué defensas los detienen.

Si estás configurando tu primer VPS, empieza por los primeros 5 pasos de seguridad. Esa sección sola bloquea más del 90% de los ataques automatizados.

Si eres admin con experiencia, usa los enlaces para ir directamente a la capa que necesitas.

Esta guía cubre Debian 12 y Ubuntu 24.04. Todos los comandos han sido probados en ambos.

¿Qué ataques recibe un Linux VPS recién creado?

Un VPS con IP pública recibe ataques automatizados a los pocos segundos de estar online. Las botnets escanean continuamente todo el espacio IPv4. Los ataques más comunes son credential stuffing sobre SSH, escaneo de puertos en busca de servicios expuestos y explotación de vulnerabilidades conocidas en software sin parchear.

Entender el modelo de amenazas da contexto a cada recomendación a continuación. Esto es lo que ocurre realmente:

Escaneo automatizado

Las botnets escanean el rango completo de IPv4 de forma constante. Proyectos como Shodan y Censys indexan cada puerto accesible. Tu servidor no es un objetivo específico. Lo encuentran porque existe.

En la primera hora tras el aprovisionamiento, espera:

200+ intentos de login SSH desde IPs distribuidas
Escaneos de puertos buscando bases de datos (3306, 5432), servidores web (80, 443) y paneles de administración
Peticiones a rutas vulnerables conocidas (/wp-admin, /phpmyadmin, /.env)

Credential stuffing y fuerza bruta

Los atacantes usan bases de datos de credenciales filtradas para probar combinaciones de usuario/contraseña contra tu servicio SSH. Rotan entre root, admin, ubuntu, deploy y otros nombres comunes. Si la autenticación por contraseña está habilitada con una clave débil, el compromiso ocurre en minutos.

Supply chain y post-compromiso

Una vez dentro, los atacantes instalan cryptominers, añaden backdoors SSH o usan tu servidor como relay para ataques adicionales. Algunos instalan rootkits que sobreviven reinicios. Un VPS comprometido puede usarse para atacar otros servidores, lo que te hace responsable del tráfico.

También existe una tendencia creciente de ataques a la supply chain dirigidos a repositorios de paquetes y scripts de instalación. El patrón curl | bash, común en muchas guías, ejecuta código arbitrario de internet sin verificación. Evítalo. Descarga los scripts, verifica los checksums, luego ejecuta.

Reconocimiento mediante divulgación de versiones

Los atacantes identifican el software de tu servidor para encontrar exploits correspondientes. Un servidor web que responde con Server: nginx/1.24.0 o un banner SSH que revela la versión exacta de OpenSSH le dice al atacante exactamente qué CVEs probar. Ocultar la versión es un paso pequeño, pero elimina el targeting de bajo esfuerzo. A lo largo de esta guía y los tutoriales enlazados, verás cómo deshabilitar la divulgación de versiones para cada servicio.

Qué implica esto para tus defensas

Cada capa de esta guía aborda vectores de ataque específicos:

Vector de Ataque	Capa de Defensa
Fuerza bruta SSH	Auth por clave SSH, Fail2Ban
Escaneo de puertos	Firewall (UFW/nftables)
Credential stuffing	Deshabilitar auth por contraseña, usuario no-root
Vulnerabilidades sin parchear	Actualizaciones de seguridad automáticas
Acceso no autorizado a servicios admin	VPN (WireGuard/Tailscale)
Escalada de privilegios	Permisos de usuario, sudo

¿Cuáles son los primeros 5 pasos de seguridad en un nuevo VPS?

Si no haces nada más, haz estas cinco cosas. Tardan menos de 15 minutos y bloquean la gran mayoría de ataques automatizados: 1) actualizar todos los paquetes, 2) crear un usuario no-root con sudo, 3) configurar autenticación SSH por clave y deshabilitar contraseñas, 4) activar un firewall, 5) instalar Fail2Ban.

Aquí está la secuencia de inicio rápido. Cada paso enlaza a un tutorial detallado.

1. Actualizar todos los paquetes

apt update && apt upgrade -y

Esto parchea vulnerabilidades conocidas. En un VPS recién creado, la imagen base puede llevar semanas o meses sin aplicar parches de seguridad.

2. Crear un usuario no-root

adduser deploy
usermod -aG sudo deploy

Trabajar como root significa que cualquier error o exploit tiene acceso total al sistema. Un usuario sudo requiere escalada de privilegios explícita.

3. Configurar autenticación SSH por clave

En tu máquina local, genera un par de claves Ed25519 si no tienes uno:

ssh-keygen -t ed25519 -C "your-email@example.com"

Cópialo a tu servidor:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@your-server-ip

Luego en el servidor, edita /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Reinicia SSH. En Ubuntu 24.04, SSH usa activación basada en socket:

# Ubuntu 24.04
sudo systemctl restart ssh.socket

# Debian 12
sudo systemctl restart sshd

Verifica antes de desconectarte: abre un segundo terminal y confirma que puedes iniciar sesión con tu clave como el nuevo usuario. Nunca cierres tu sesión actual hasta haber verificado el acceso.

4. Activar un firewall

# Instalar UFW (preinstalado en Ubuntu, requiere instalación en Debian)
sudo apt install ufw -y

# Permitir SSH antes de activar
sudo ufw allow ssh

# Activar el firewall
sudo ufw enable

# Verificar
sudo ufw status

Deberías ver SSH (puerto 22) listado como ALLOW. Todo lo demás está denegado por defecto.

5. Instalar Fail2Ban

sudo apt install fail2ban -y

Crea una configuración local de jail:

sudo tee /etc/fail2ban/jail.d/sshd.conf > /dev/null << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 600
bantime = 1800
EOF

En Debian 12, Fail2Ban necesita leer desde journald en lugar de auth.log:

# Solo Debian 12
echo "sshd_backend = systemd" | sudo tee -a /etc/fail2ban/paths-debian.conf

Inicia y habilita el servicio:

sudo systemctl enable --now fail2ban

Verifica que está funcionando:

sudo systemctl status fail2ban
sudo fail2ban-client status sshd

Deberías ver el jail de sshd listado como activo con 0 IPs baneadas. En pocas horas empezarás a ver bloqueos.

¿Cómo protege tu servidor el hardening de SSH?

SSH es la puerta principal de tu servidor y el objetivo número uno de los ataques automatizados. Hardening de SSH significa reemplazar la autenticación por contraseña con claves criptográficas, deshabilitar el login como root y limitar qué usuarios y algoritmos acepta el servidor. Estos cambios reducen la superficie de ataque SSH de "prueba cualquier contraseña" a "presenta exactamente esta clave privada."

Más allá de lo básico cubierto en los primeros 5 pasos, una configuración SSH endurecida incluye:

Solo claves Ed25519. Más rápidas y seguras que RSA. La clave tiene 256 bits pero proporciona 128 bits de seguridad, equivalente a RSA-3072.
Timeout de inactividad. Desconecta sesiones inactivas para evitar que terminales abandonados sean secuestrados:

ClientAliveInterval 300
ClientAliveCountMax 2

Restringir usuarios. Limita el acceso SSH a cuentas específicas:

AllowUsers deploy

Deshabilitar métodos de autenticación no usados:

KbdInteractiveAuthentication no
X11Forwarding no

Ocultar el banner de versión SSH. Aunque OpenSSH no permite suprimir completamente su versión de protocolo, puedes eliminar banners personalizados y limitar la fuga de información:

Banner none
DebianBanner no

Tras cualquier cambio en sshd_config, valida la sintaxis antes de reiniciar:

sudo sshd -t

Si el comando no produce ninguna salida, la configuración es válida. Luego reinicia SSH y verifica que todavía puedes iniciar sesión desde un segundo terminal. Siempre prueba desde una segunda sesión. Si la configuración está rota, aún tienes tu conexión existente.

Para el tutorial completo de hardening SSH con configuraciones probadas para Debian 12 y Ubuntu 24.04, ver .

¿Por qué necesita firewall tu VPS?

Un firewall controla qué tráfico de red llega a tu servidor. Sin uno, cada servicio que ejecutes está expuesto a internet. Una base de datos en el puerto 5432, un servidor de desarrollo en el puerto 3000, una instancia de Redis en el puerto 6379: todos accesibles por cualquiera. El firewall garantiza que solo los puertos que abres explícitamente sean accesibles.

Debian 12 y Ubuntu 24.04 usan nftables como framework de filtrado de paquetes a nivel de kernel. UFW (Uncomplicated Firewall) se asienta encima como interfaz amigable. Para la mayoría de casos de uso con VPS, UFW es la opción correcta.

UFW vs nftables: cuándo usar cada uno

	UFW	nftables
Mejor para	Servidores únicos, apps web	Multi-servidor, routing avanzado
Curva de aprendizaje	Minutos	Horas o días
Por defecto en	Ubuntu (preinstalado)	Debian 12 (backend)
Sintaxis de reglas	`ufw allow 443/tcp`	Tablas, cadenas, expresiones de reglas
Cuándo cambiar	N/A	Necesitas logging por paquete, rate limiting, NAT complejo

Una configuración típica de firewall para servidor web con UFW:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Verifica las reglas:

sudo ufw status numbered

Cada puerto abierto es un punto de entrada potencial. Abre solo lo que tu aplicación necesita. Si eliminas un servicio, elimina también su regla de firewall.

Para configuración detallada de firewall incluyendo reglas nftables, rate limiting y control de acceso por puerto, ver .

¿Cómo detiene Fail2Ban los ataques de fuerza bruta?

Fail2Ban monitoriza archivos de log (o journald en Debian 12) en busca de intentos fallidos de autenticación repetidos y banea temporalmente las IPs ofensoras usando reglas de firewall. Convierte un ataque de fuerza bruta de "prueba 10.000 contraseñas" a "prueba 3 contraseñas, queda bloqueado 30 minutos, empieza de nuevo desde otra IP."

Cómo funciona

Fail2Ban vigila los logs de autenticación SSH
Tras maxretry fallos dentro de findtime, crea una regla de firewall bloqueando esa IP
Tras expirar bantime, se elimina la regla
Los atacantes persistentes rotan IPs, pero el rate limit hace que el credential stuffing sea impracticable

Configuración recomendada para un VPS

Los valores por defecto son demasiado permisivos para un servidor público. Aquí hay una configuración para producción:

sudo tee /etc/fail2ban/jail.d/sshd.conf > /dev/null << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 600
bantime = 3600
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 86400
EOF

Esta configuración banea una IP durante 1 hora tras 3 fallos. Si la misma IP vuelve, el ban se duplica cada vez, hasta 24 horas. Es más efectivo que un tiempo de ban fijo porque los escáneres automatizados acabarán dando menor prioridad a tu servidor.

Reinicia Fail2Ban para aplicar:

sudo systemctl restart fail2ban

Comprueba los bans activos:

sudo fail2ban-client status sshd

Observa los bans en tiempo real:

sudo tail -f /var/log/fail2ban.log

Para la guía completa de configuración de Fail2Ban cubriendo jails personalizados para Nginx, Postfix y otros servicios, ver .

¿Cómo reducen los permisos de usuario tu superficie de ataque?

Ejecutar servicios como root le da a un atacante acceso total al sistema si ese servicio es comprometido. El principio de mínimo privilegio significa que cada proceso corre con los permisos mínimos que necesita. Un compromiso del servidor web no debería dar acceso a tu base de datos, tus claves SSH ni tu configuración del sistema.

Prácticas clave

Nunca ejecutes servicios de aplicación como root. Servidores web, bases de datos y runtimes de aplicaciones deben tener su propio usuario de sistema:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/myapp myapp

El flag --system crea un usuario sin login con directorio home. El --shell /usr/sbin/nologin previene el login interactivo. Este usuario puede ejecutar tu aplicación pero no puede acceder por SSH ni ejecutar comandos arbitrarios.

Restringe el acceso sudo. Solo los usuarios en el grupo sudo deben tener privilegios elevados. Audita quién tiene sudo:

getent group sudo

Establece permisos de archivo correctamente. Los archivos de configuración con contraseñas o API keys no deben ser legibles por todos:

# Restringir un archivo de configuración solo al propietario
sudo chmod 600 /etc/myapp/config.env
sudo chown myapp:myapp /etc/myapp/config.env

# Verificar
ls -la /etc/myapp/config.env

Deberías ver permisos -rw-------, lo que significa que solo el propietario puede leer y escribir.

Usa archivos de entorno para secretos. En lugar de escribir credenciales en archivos de configuración, crea un archivo de entorno dedicado con permisos restringidos:

sudo tee /etc/myapp/env > /dev/null << 'EOF'
DB_PASSWORD=your-generated-password
API_KEY=your-api-key
EOF

sudo chmod 600 /etc/myapp/env
sudo chown myapp:myapp /etc/myapp/env

Referencíalo en las unidades de systemd con EnvironmentFile=/etc/myapp/env. Genera contraseñas con openssl rand -base64 32 en lugar de elegirlas manualmente.

Para la guía completa sobre gestión de usuarios Linux, configuración de sudo y modelos de permisos, ver .

¿Por qué deberías automatizar las actualizaciones de seguridad?

El software sin parchear es uno de los vectores de ataque más explotados. Cuando se divulga una vulnerabilidad, los atacantes comienzan a escanear servidores sin parchear en cuestión de horas. Las actualizaciones manuales dejan tu servidor vulnerable desde la divulgación hasta que recuerdas ejecutar apt upgrade. Las actualizaciones de seguridad automáticas cierran esa ventana.

Configurar unattended-upgrades

Ubuntu 24.04 incluye unattended-upgrades en su instalación de servidor por defecto, pero algunos proveedores de VPS distribuyen imágenes mínimas sin él. Debian 12 también requiere instalación. En cualquiera de las dos distribuciones, instálalo si no está presente:

sudo apt install unattended-upgrades apt-listchanges -y
sudo dpkg-reconfigure -plow unattended-upgrades

Verifica que está activo:

cat /etc/apt/apt.conf.d/20auto-upgrades

Deberías ver:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

El "1" significa diario. Las listas de paquetes se actualizan cada día y los parches de seguridad se instalan automáticamente.

Qué se actualiza

Por defecto, solo se instalan actualizaciones de seguridad del repositorio oficial. Esta es la configuración correcta para un servidor de producción. Las actualizaciones de funcionalidades y los cambios de versión mayor siguen requiriendo intervención manual, lo que evita que las actualizaciones desatendidas rompan tu aplicación.

Monitorizar actualizaciones

Comprueba qué se ha instalado automáticamente:

sudo cat /var/log/unattended-upgrades/unattended-upgrades.log

Configura notificaciones por email de las actualizaciones aplicadas editando /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "on-change";

Para el reinicio automático cuando las actualizaciones del kernel lo requieran:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Activa los reinicios automáticos solo si tu aplicación maneja reinicios de forma correcta. Para la mayoría de configuraciones, una revisión manual semanal es mejor que reinicios inesperados.

Para la guía completa de configuración incluyendo monitorización y resolución de problemas, ver .

¿Cuándo deberías añadir acceso VPN a tu VPS?

Añade acceso VPN cuando ejecutes servicios que nunca deben estar expuestos a internet público: paneles de administración, bases de datos, dashboards de monitorización o APIs internas. Una VPN crea un túnel cifrado para que estos servicios sean accesibles solo desde dispositivos en tu red privada. En lugar de abrir el puerto 3000 al mundo y esperar que tu autenticación aguante, lo cierras completamente desde internet y accedes a través de la VPN.

WireGuard vs Tailscale

	WireGuard	Tailscale
Tiempo de configuración	15-30 minutos por peer	2-5 minutos en total
Configuración	Intercambio manual de claves, archivos de config	Login SSO, automático
NAT traversal	Reenvío de puertos manual	Automático
Control	Total, gestionas todo	El servidor de coordinación es de terceros
Coste	Gratuito, self-hosted	Gratuito hasta 100 dispositivos
Mejor para	Infraestructura fija, control total	Equipos, dispositivos dinámicos, setup rápido

Elige WireGuard cuando quieras control total sobre tu red, tengas infraestructura estática y te sientas cómodo gestionando pares de claves y archivos de configuración.

Elige Tailscale cuando necesites configuración rápida en múltiples dispositivos, trabajes en equipo o quieras NAT traversal automático sin reenvío de puertos.

Ambos usan el protocolo WireGuard por debajo. Tailscale es WireGuard con orquestación.

Qué poner detrás de la VPN

Puertos de bases de datos (PostgreSQL 5432, MySQL 3306, Redis 6379)
Paneles de administración (phpMyAdmin, Adminer, Grafana)
Endpoints de monitorización (Prometheus, Node Exporter)
APIs internas no destinadas al consumo público
Acceso SSH (doble seguro: auth por clave + VPN)

Un patrón común: mantén los puertos 80 y 443 abiertos para tu aplicación web pública. Todo lo demás pasa por la VPN. Las reglas de tu firewall se convierten en:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 51820/udp  # WireGuard
# SSH solo desde la subred VPN
sudo ufw allow from 10.0.0.0/24 to any port 22

Para la configuración paso a paso de WireGuard y Tailscale en tu VPS, ver .

¿Qué hay de cambiar el puerto SSH?

Muchas guías recomiendan cambiar SSH del puerto 22 a un puerto de numeración alta. Eso es seguridad por oscuridad. Detiene a los bots más descuidados que solo prueban el puerto 22. No detiene a ningún atacante que ejecute un escaneo de puertos, lo cual tarda segundos.

El coste real: ahora tienes que recordar -p 2222 en cada comando SSH, configurarlo en cada script de despliegue y pipeline de CI, y arriesgarte a quedarte bloqueado si lo olvidas. La autenticación SSH por clave con Fail2Ban proporciona seguridad real. Cambiar el puerto añade complejidad operacional con ganancia mínima.

La misma lógica aplica a deshabilitar IPv6. Si tu servidor tiene una dirección IPv6, deshabilitarla no elimina la superficie de ataque. Rompe la compatibilidad futura. Configura tu firewall tanto para IPv4 como para IPv6.

Capas de seguridad de un vistazo

Cada capa de esta guía aborda una parte específica de tu defensa. Así se apilan:

Capa	Qué Protege	Prioridad
Actualizaciones del sistema	Parchea vulnerabilidades conocidas	Hazlo primero
Permisos de usuario	Limita el radio de explosión de un compromiso	Hazlo primero
Hardening SSH	Bloquea acceso remoto no autorizado	Hazlo primero
Firewall	Controla la exposición de red	Hazlo primero
Fail2Ban	Frena ataques de fuerza bruta	Hazlo primero
Actualizaciones automáticas	Mantiene parches al día a largo plazo	Configura en la primera semana
Acceso VPN	Oculta servicios internos	Cuando ejecutes servicios no públicos
Hardening del kernel	Limita técnicas de exploit	Avanzado, sistemas de producción
Logging de auditoría	Detecta compromiso a posteriori	Avanzado, cumplimiento normativo

Las primeras cinco capas son innegociables para cualquier servidor conectado a internet. Las capas restantes añaden profundidad según lo que ejecutes y tus requisitos de cumplimiento.

Ninguna capa sola es suficiente. El hardening SSH sin firewall sigue dejando servicios expuestos. Un firewall sin actualizaciones automáticas deja vulnerabilidades conocidas abiertas. Las capas trabajan juntas. Cada una captura lo que las otras dejan pasar.

¿Cuándo deberías usar hosting gestionado?

Si la gestión de seguridad te quita tiempo para construir tu producto, considera el hosting gestionado. No es un fracaso. Es una decisión de asignación de recursos.

Señales de que deberías considerar hosting gestionado:

Tienes un servicio en producción pero no tienes tiempo para monitorizar avisos de seguridad
Tu equipo no tiene experiencia en administración Linux
Necesitas certificaciones de cumplimiento (SOC 2, ISO 27001) y no puedes formar equipo para el proceso de auditoría
Has sido comprometido antes y te falta experiencia para investigarlo

Un servidor gestionado de un proveedor como Virtua Cloud se encarga del parcheo del SO, gestión del firewall, detección de intrusiones y copias de seguridad. Tú te centras en tu aplicación. El proveedor gestiona la capa de seguridad de la infraestructura.

Para equipos que quieren la flexibilidad de un VPS con cobertura parcial de seguridad, existe un punto intermedio: provisiona un VPS no gestionado para desarrollo y staging, y usa hosting gestionado para producción.

¿Algo ha salido mal?

Verifica tu acceso SSH

Si quedas bloqueado tras cambiar la configuración SSH:

Usa la consola web o consola serie de tu proveedor de VPS para acceder al servidor
Comprueba la sintaxis de la configuración SSH: sudo sshd -t
Verifica que tu clave está en ~/.ssh/authorized_keys para el usuario correcto
Revisa los logs de SSH: journalctl -u ssh -n 50 (Ubuntu) o journalctl -u sshd -n 50 (Debian)

Verifica tu firewall

Si un servicio no es accesible:

sudo ufw status numbered

Asegúrate de que el puerto aparece como ALLOW. Si acabas de activar UFW y olvidaste permitir SSH primero, usa la consola web del proveedor.

Verifica Fail2Ban

Si una IP legítima fue baneada:

# Comprobar si la IP está baneada
sudo fail2ban-client status sshd

# Desbanear una IP específica
sudo fail2ban-client set sshd unbanip 1.2.3.4

Lee los logs

Los logs te dicen qué ocurrió:

# Autenticación SSH
journalctl -u ssh -f     # Ubuntu 24.04
journalctl -u sshd -f    # Debian 12

# Actividad de Fail2Ban
sudo tail -f /var/log/fail2ban.log

# Bloqueos del firewall (si usas logging de nftables)
journalctl -k | grep nft

# Mensajes del sistema
journalctl -p err -b

Acostúmbrate a leer la salida de los logs. Cada vez que algo falla, la respuesta casi siempre está en los logs.

Próximos pasos

Cada sección anterior enlaza a un tutorial detallado:

Empieza por los primeros 5 pasos de seguridad si todavía no los has hecho, luego trabaja los tutoriales en orden.

Copyright 2026 Virtua.Cloud. Todos los derechos reservados. Este contenido es una obra original del equipo de Virtua.Cloud. La reproducción, republicación o redistribución sin permiso escrito está prohibida.