Cómo proteger un VPS Linux: hardening básico paso a paso

Un VPS expuesto a internet sin endurecer es un objetivo automático para miles de bots maliciosos cada día. Brute force a SSH, escaneo de puertos, intentos de explotación de servicios desactualizados — todo eso ocurre minutos después de provisionar el VPS. La buena noticia: con 30-60 minutos de hardening básico, bloqueas el 99% de estos ataques.

En esta guía vamos a aplicar las 12 medidas de seguridad esenciales para un VPS Linux (Ubuntu/Debian). Sin convertirte en experto en seguridad, vas a quedar protegido contra los ataques más comunes.

Por qué hardening desde el día 1

• 24-48 horas tras provisionar un VPS, los logs muestran 100-1.000+ intentos de login SSH desde IPs random.
• El 90% de hackeos a VPS son por configuraciones básicas no aplicadas: SSH con password, fail2ban ausente, puertos abiertos innecesarios.
• Costo de un hackeo: tiempo de limpieza (10-40 horas), pérdida de datos, blacklisting de IP, posiblemente clientes afectados.

Inversión: una hora de hardening. ROI: enorme.

Antes de empezar

• Asume VPS con Ubuntu 22.04 LTS o 24.04 LTS (o Debian 12).
• Acceso SSH con credenciales del proveedor.
• 2 ventanas SSH abiertas durante los cambios (si una se bloquea, no quedas afuera).

Medida 1: Crear un usuario no-root

Trabajar como root es peligroso: cualquier comando mal escrito o exploit te compromete totalmente.

adduser deploy
usermod -aG sudo deploy

Copia tu clave SSH al nuevo usuario:

rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Verifica desde otra terminal:

ssh deploy@tu-ip-vps
sudo ls /root      # debe pedir contraseña pero funcionar

A partir de ahora, nunca uses root directo.

Medida 2: Configurar SSH con claves (no password)

El SSH con password es el vector #1 de ataques de fuerza bruta.

A. Genera una clave SSH (si no tienes)

En tu computadora local:

ssh-keygen -t ed25519 -C "tu-correo@dominio.com"

Te genera ~/.ssh/id_ed25519 (privada) y ~/.ssh/id_ed25519.pub (pública). Nunca compartas la privada.

B. Copia la pública al VPS

ssh-copy-id deploy@tu-ip-vps

O manualmente:

cat ~/.ssh/id_ed25519.pub | ssh deploy@tu-ip-vps "cat >> ~/.ssh/authorized_keys"

C. Prueba el login con clave

ssh deploy@tu-ip-vps

Debe entrar sin pedir contraseña.

D. Deshabilita login por contraseña

Edita /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Cambia/agrega:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
PermitEmptyPasswords no

Reinicia SSH:

sudo systemctl restart ssh

Medida 3: Cambiar el puerto SSH (opcional pero útil)

El puerto 22 es el primer escaneado. Cambiarlo a otro (ej: 2222) reduce 90% de los intentos automáticos.

En /etc/ssh/sshd_config:

Port 2222

Abre el puerto en el firewall antes de reiniciar SSH (siguiente sección).

sudo ufw allow 2222/tcp
sudo systemctl restart ssh

Conéctate ahora con:

ssh -p 2222 deploy@tu-ip-vps

Medida 4: Configurar firewall UFW

UFW (Uncomplicated Firewall) es un wrapper de iptables fácil de usar.

sudo apt install -y ufw

Reglas básicas:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp comment "SSH custom"
sudo ufw allow 80/tcp comment "HTTP"
sudo ufw allow 443/tcp comment "HTTPS"
sudo ufw enable

Verifica:

sudo ufw status verbose

Regla mental: solo abre los puertos que necesites activamente. Cada puerto extra es superficie de ataque.

Medida 5: Instalar fail2ban

Fail2ban bloquea IPs automáticamente tras múltiples intentos fallidos de login.

sudo apt install -y fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Configuración recomendada

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Busca y modifica:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port = 2222  # si cambiaste el puerto
filter = sshd
logpath = %(sshd_log)s

Reinicia:

sudo systemctl restart fail2ban

Verifica que esté trabajando:

sudo fail2ban-client status sshd

En 48 horas verás IPs banneadas en Banned IP list.

Medida 6: Actualizaciones automáticas de seguridad

Parches CVE nuevos salen semanalmente. No aplicarlos te deja vulnerable a exploits conocidos.

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Selecciona Yes cuando pregunte.

Edita la config:

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Asegúrate de tener:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
};
Unattended-Upgrade::Automatic-Reboot "false";

Esto aplica parches automáticos, pero no reinicia el servidor solo (lo haces tú en una ventana segura).

Medida 7: Configurar swap (opcional pero recomendado)

Si tu VPS tiene poca RAM, swap evita que un pico de uso lo tumbe.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Verifica:

free -h

Debes ver swap activo.

Medida 8: Deshabilitar servicios innecesarios

Lista qué corre:

sudo systemctl list-units --type=service --state=active

Si ves servicios que no usas (postfix, apache2, etc.), desactívalos:

sudo systemctl stop nombre-servicio
sudo systemctl disable nombre-servicio

Y elimínalos si no son críticos:

sudo apt purge nombre-servicio

Menos servicios = menos superficie de ataque.

Medida 9: Monitorear logs

Logs de SSH

sudo tail -50 /var/log/auth.log | grep -i "failed\|invalid"

Si ves CIENTOS de intentos fallidos, fail2ban está funcionando — los banneados aparecen luego.

Logs del firewall

sudo tail -50 /var/log/ufw.log

Recursos en tiempo real

sudo apt install -y htop
htop

Ver CPU, RAM, procesos en vivo.

Medida 10: Configurar 2FA en SSH (avanzado)

Para máxima seguridad, suma 2FA por TOTP además de tu clave SSH:

sudo apt install -y libpam-google-authenticator
google-authenticator

Te genera un código QR para Google Authenticator, Authy, etc. Configura para forzar 2FA en SSH:

sudo nano /etc/pam.d/sshd

Añade al final:

auth required pam_google_authenticator.so

Y en /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Reinicia:

sudo systemctl restart ssh

A partir de ahora: clave SSH + código TOTP para entrar.

Medida 11: Auditar puertos abiertos

Verifica qué está escuchando:

sudo ss -tulpn

Salida típica:

LISTEN  0   128   0.0.0.0:2222    0.0.0.0:*   users:(("sshd",pid=1234))
LISTEN  0   511   0.0.0.0:80      0.0.0.0:*   users:(("nginx",pid=5678))
LISTEN  0   511   0.0.0.0:443     0.0.0.0:*   users:(("nginx",pid=5678))
LISTEN  0   80    127.0.0.1:3306  0.0.0.0:*   users:(("mariadbd",pid=9012))

Regla: servicios internos (MySQL, Redis) deben escuchar solo en 127.0.0.1, NO en 0.0.0.0 (todas las interfaces).

Si ves MySQL en 0.0.0.0:3306, edita /etc/mysql/mariadb.conf.d/50-server.cnf:

bind-address = 127.0.0.1

Y reinicia el servicio.

Medida 12: Backups (ya cubierto pero crítico)

Hardening protege contra ataques. Backups son tu plan B si algo falla.

• Snapshots del proveedor: 1 click setup, vive en el proveedor.
• rsync a otro servidor: control total.
• ServerAvatar (incluido sin costo con VPS Moshipp): backups visuales con destinos remotos (S3, Dropbox, Drive).
• Borg/Restic: backups incrementales encriptados para producción seria.

Detalles completos en la guía de backups 3-2-1.

Checklist final de hardening

Antes de declarar tu VPS “seguro”:

• Usuario no-root creado y verificado.
• SSH con clave (no password).
• PermitRootLogin = no.
• Puerto SSH cambiado (opcional).
• UFW configurado y activo.
• fail2ban funcionando con bans visibles.
• Unattended-upgrades aplicando seguridad.
• Swap configurado.
• Servicios innecesarios desactivados.
• Logs revisados semanalmente.
• 2FA opcional aplicado.
• Servicios internos en 127.0.0.1.
• Backups automáticos a destino remoto.
• Plan de recuperación documentado.

Imprime esta lista. Pásala mensualmente.

Hardening adicional para producción

Si tu VPS hostea cargas críticas, suma:

CrowdSec (alternativa moderna a fail2ban)

curl -s https://install.crowdsec.net | sudo sh
sudo apt install -y crowdsec

CrowdSec consulta una base colaborativa de IPs maliciosas + protege contra patrones de ataque, no solo brute force.

Lynis (auditoría automatizada)

sudo apt install -y lynis
sudo lynis audit system

Te entrega un reporte con score y recomendaciones específicas según tu sistema.

AIDE (File Integrity Monitoring)

Detecta cambios no autorizados en archivos críticos:

sudo apt install -y aide
sudo aideinit
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
sudo aide --check

Ejecútalo en cron diariamente.

Restricciones de red por país (geoblocking)

Si solo vendes en Colombia y mucho ataque viene de Rusia/China, bloquea esos países con módulos como xtables-addons o vía Cloudflare al frente (ver guía de Cloudflare).

¿Qué tan seguro queda mi VPS?

Con las 12 medidas básicas + opcionales avanzadas, tu VPS bloquea:

• 99% de ataques automatizados (botnets, scripts kiddies).
• Brute force de SSH: fail2ban + clave SSH + 2FA = imposible en la práctica.
• Explotación de servicios desactualizados: actualizaciones automáticas + auditoría.
• Lateral movement: servicios internos no expuestos.

Lo que NO te protege:

• Ataques 0-day (vulnerabilidades sin parche aún).
• Ataques dirigidos profesionales (APTs).
• Errores humanos: contraseñas filtradas, claves SSH compartidas.
• Compromiso de tu computadora local (donde está la clave privada).

Para 99% de proyectos PYME en Colombia, este hardening es suficiente. Para fintech, salud o gobierno, suma compliance específico.

Preguntas frecuentes

¿Hardening reduce el rendimiento del VPS?

Negligible. fail2ban y UFW consumen poca RAM/CPU. Las medidas más pesadas son monitoreo de logs (AIDE) o IDS profesional (CrowdSec), pero impacto sigue siendo < 5% típicamente.

¿Necesito hardening si uso un panel como ServerAvatar?

Sí, son complementarios. ServerAvatar gestiona aplicaciones (Nginx, BD, SSL, deploys). El hardening protege el sistema operativo subyacente. Aplica ambos.

¿Cuándo debo cambiar las claves SSH?

Si se ven comprometidas (laptop robada, ex empleado), inmediatamente. En general, rotar cada 1-2 años es buena práctica. Genera la nueva clave, agrégala al VPS, borra la vieja.

¿UFW reemplaza el firewall del proveedor?

No. Lo complementa. El firewall del proveedor (a nivel hipervisor) es la primera línea de defensa. UFW dentro del VPS es la segunda. Defense in depth.

¿Qué hago si fail2ban me bloquea por error?

Conéctate desde otra IP (4G del celular, VPN) y desbloquéate: `sudo fail2ban-client set sshd unbanip TU.IP`. Para evitar bloquearte: añade tu IP fija a la whitelist en `/etc/fail2ban/jail.local`.

¿Las actualizaciones automáticas pueden romper algo?

Raro pero posible. Por eso unattended-upgrades aplica solo parches de **seguridad** (no upgrades mayores). Los upgrades mayores los haces tú manualmente revisando notas de release.

¿Linux es más seguro que Windows Server?

En general sí, por varios factores: menor superficie de ataque, parches más rápidos, comunidad open source que audita. Pero Windows bien administrado puede ser igual de seguro. La 'seguridad' depende más de quién administre que del SO.

Conclusión

El hardening de un VPS Linux no es opcional en 2026. Las 12 medidas que cubrimos toman menos de una hora y bloquean el 99% de ataques automatizados.

Aplica todo en este orden: usuario no-root → SSH con clave → desactivar password auth → UFW → fail2ban → unattended-upgrades → 2FA opcional. Documenta tu trabajo, repítelo cada vez que provisiones un nuevo VPS.

En Moshipp, todos los VPS Cloud incluyen ServerAvatar sin costo para gestionar lo visual (Nginx, SSL, backups), y nuestro soporte en español te ayuda con el hardening si nunca tocaste un Linux. Y nuestro VPS N8N viene pre-endurecido para que arranques con N8N en minutos.