Cómo Securizar un VPS Linux: Guía Completa 2025

Un VPS sin securizar es una invitación a los atacantes. Bots automáticos escanean internet constantemente buscando servidores vulnerables. Si tu VPS tiene la configuración por defecto, es cuestión de tiempo.

La buena noticia: securizar un VPS Linux no es difícil. Con las medidas correctas, puedes tener un servidor muy seguro en unas horas.

Esta guía cubre todas las medidas de seguridad esenciales, desde lo básico hasta configuraciones avanzadas.

La realidad de la seguridad en servidores

Los números son claros

Un servidor expuesto recibe miles de intentos de login al día
El tiempo medio para que un servidor vulnerable sea comprometido es de horas
El 90% de los ataques exitosos explotan configuraciones por defecto

Los atacantes son automáticos

No es alguien sentado intentando entrar en tu servidor. Son bots que:

Escanean rangos de IPs
Detectan servicios corriendo
Prueban credenciales comunes
Explotan vulnerabilidades conocidas

Tu trabajo es hacer que tu servidor no sea un objetivo fácil.

Las capas de seguridad

La seguridad funciona en capas. Si una falla, las otras te protegen:

Acceso SSH - Primera línea de defensa
Firewall - Controla qué entra y sale
Servicios - Minimiza superficie de ataque
Actualizaciones - Parcha vulnerabilidades
Monitorización - Detecta problemas
Backups - Plan B si todo falla

Capa 1: Securizar SSH

SSH es la puerta principal a tu servidor. Si un atacante entra por SSH, tiene control total.

1.1 Usar claves en lugar de contraseñas

Las contraseñas se pueden adivinar. Las claves SSH son prácticamente imposibles de crackear.

En tu ordenador local:

ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id usuario@TU_IP

En el servidor, edita /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes

El usuario root existe en todos los Linux. Los atacantes lo saben.

PermitRootLogin no

Crea un usuario normal y usa sudo cuando necesites privilegios.

1.3 Cambiar el puerto SSH

El puerto 22 es el objetivo de todos los escaneos. Cambiarlo reduce el ruido drásticamente.

Port 2222  # Elige un puerto alto no estándar

No olvides:

Abrir el nuevo puerto en el firewall ANTES de cerrar sesión
Actualizar tu cliente SSH con el nuevo puerto

1.4 Limitar usuarios que pueden conectar

Solo permite SSH a usuarios específicos:

AllowUsers tuusuario otrousuario

1.5 Timeout de sesiones inactivas

Desconecta sesiones abandonadas:

ClientAliveInterval 300
ClientAliveCountMax 2

1.6 Configuración SSH completa recomendada

# /etc/ssh/sshd_config

Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers tuusuario
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
MaxAuthTries 3

Reinicia SSH después de cambios:

sudo systemctl restart sshd

Capa 2: Firewall con UFW

UFW (Uncomplicated Firewall) es la forma más simple de gestionar iptables.

2.1 Instalación y configuración básica

sudo apt install ufw -y

# Política por defecto: denegar todo entrante
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Permitir SSH (¡IMPORTANTE: hazlo antes de activar!)
sudo ufw allow 2222  # Tu puerto SSH

# Permitir HTTP y HTTPS si tienes web
sudo ufw allow 80
sudo ufw allow 443

# Activar
sudo ufw enable

2.2 Ver estado y reglas

sudo ufw status verbose

2.3 Reglas adicionales comunes

# Permitir desde IP específica
sudo ufw allow from 192.168.1.100

# Permitir puerto solo desde IP
sudo ufw allow from 192.168.1.100 to any port 3306

# Limitar conexiones (anti brute-force)
sudo ufw limit 2222

2.4 Eliminar reglas

sudo ufw status numbered
sudo ufw delete NUMERO

Capa 3: Fail2ban (anti fuerza bruta)

Fail2ban monitoriza logs y banea IPs que intentan ataques.

3.1 Instalación

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

3.2 Configuración básica

Crea /etc/fail2ban/jail.local:

sudo nano /etc/fail2ban/jail.local

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

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 24h

3.3 Comandos útiles

# Ver IPs baneadas
sudo fail2ban-client status sshd

# Desbanear IP
sudo fail2ban-client set sshd unbanip 192.168.1.100

# Ver logs
sudo tail -f /var/log/fail2ban.log

Capa 4: Actualizaciones automáticas

Las vulnerabilidades se descubren constantemente. Los parches deben aplicarse rápido.

4.1 Actualizaciones automáticas de seguridad

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

4.2 Configuración avanzada

Edita /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Unattended-Upgrade::AutoFixInterruptedDpkg "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";

4.3 Notificaciones por email

Unattended-Upgrade::Mail "[email protected]";
Unattended-Upgrade::MailReport "on-change";

Capa 5: Minimizar superficie de ataque

5.1 Eliminar servicios innecesarios

Lista servicios corriendo:

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

Desactiva lo que no necesites:

sudo systemctl disable SERVICIO
sudo systemctl stop SERVICIO

5.2 Cerrar puertos innecesarios

Verifica qué puertos están abiertos:

sudo ss -tulnp

Si ves algo que no reconoces, investiga y ciérralo si no es necesario.

5.3 Deshabilitar IPv6 (si no lo usas)

Muchos ataques vienen por IPv6 mal configurado:

sudo nano /etc/sysctl.conf

Añade:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Aplica:

sudo sysctl -p

Capa 6: Permisos y usuarios

6.1 Principio de mínimo privilegio

Cada servicio corre con su propio usuario
Ningún usuario tiene más permisos de los necesarios
Root solo para administración puntual

6.2 Verificar usuarios del sistema

# Ver usuarios con shell
cat /etc/passwd | grep -v nologin | grep -v false

# Ver usuarios con UID 0 (root)
awk -F: '($3 == 0) {print}' /etc/passwd

Solo root debería tener UID 0.

6.3 Archivos sensibles

# Permisos correctos para SSH
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# Archivos de sistema
sudo chmod 644 /etc/passwd
sudo chmod 640 /etc/shadow

Capa 7: Monitorización

7.1 Logs importantes

# Intentos de login
sudo tail -f /var/log/auth.log

# Sistema general
sudo tail -f /var/log/syslog

# Kernel
sudo dmesg | tail

7.2 Herramientas de monitorización

Netdata (dashboard visual):

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Logwatch (resumen diario por email):

sudo apt install logwatch -y

Añade a /etc/profile:

if [ -n "$SSH_CLIENT" ]; then
    echo "Login SSH: $(whoami) desde $(echo $SSH_CLIENT | awk '{print $1}')" | mail -s "Login en $(hostname)" [email protected]
fi

Checklist de seguridad completo

Esencial (obligatorio)

Medida	Comando verificación	✓
SSH con claves	`grep PasswordAuth /etc/ssh/sshd_config`	☐
Root login desactivado	`grep PermitRoot /etc/ssh/sshd_config`	☐
Puerto SSH cambiado	`grep Port /etc/ssh/sshd_config`	☐
Firewall activo	`sudo ufw status`	☐
Fail2ban corriendo	`sudo systemctl status fail2ban`	☐
Actualizaciones auto	`systemctl status unattended-upgrades`	☐

Medida	Comando verificación	✓
Solo usuarios permitidos	`grep AllowUsers /etc/ssh/sshd_config`	☐
IPv6 desactivado	`cat /proc/sys/net/ipv6/conf/all/disable_ipv6`	☐
Servicios mínimos	`systemctl list-units --type=service`	☐
Monitorización activa	Según herramienta	☐

Avanzado

Medida	Descripción	✓
SELinux/AppArmor	Seguridad a nivel kernel	☐
Auditoría (auditd)	Registro detallado de acciones	☐
IDS (OSSEC, etc.)	Detección de intrusiones	☐
2FA para SSH	Autenticación de dos factores	☐

Errores de seguridad comunes

Error 1: “Mi servidor no es importante”

Los atacantes no buscan datos. Buscan recursos (para minar crypto, enviar spam, atacar otros servidores). Todo servidor es objetivo.

Error 2: Seguridad por oscuridad

Cambiar el puerto SSH ayuda contra bots, pero no es seguridad real. Es una capa adicional, no la única.

Error 3: Firewall pero puertos abiertos innecesarios

De nada sirve UFW si tienes abierto el puerto 3306 (MySQL) al mundo porque “así era más fácil conectar”.

Error 4: No revisar logs

Los ataques dejan rastro. Si no revisas logs, no sabrás que te están atacando hasta que sea tarde.

Error 5: Backups en el mismo servidor

Si te hackean, también comprometen tus backups. Siempre backup externo.

Qué hacer si sospechas una intrusión

No entres en pánico
Documenta todo lo que veas raro
Desconecta el servidor de la red si es posible
Revisa logs de auth, syslog, aplicaciones
Cambia todas las contraseñas desde otro dispositivo
Considera reinstalar si hay evidencia clara de compromiso
Aprende qué falló para no repetirlo

Auditoría de seguridad

Herramientas de auditoría

Lynis (auditoría automática):

sudo apt install lynis -y
sudo lynis audit system

ClamAV (antivirus):

sudo apt install clamav -y
sudo freshclam
sudo clamscan -r /

Escaneo externo

Verifica qué ve el mundo de tu servidor:

# Desde fuera (otro servidor o servicio online)
nmap -sV TU_IP

Preguntas frecuentes

¿Necesito todas estas medidas?

Las esenciales sí (SSH seguro, firewall, fail2ban, updates). Las avanzadas dependen de qué tan crítico sea tu servidor.

¿Esto garantiza que no me hackeen?

No hay garantía al 100%. Pero estas medidas te protegen del 99% de ataques automáticos y dificultan enormemente los dirigidos.

¿Con qué frecuencia debo revisar la seguridad?

Revisa logs semanalmente. Haz auditoría completa mensualmente. Actualiza la configuración cuando haya nuevas recomendaciones.

¿Vale la pena contratar administración gestionada?

Si la seguridad te preocupa pero no tienes tiempo o conocimientos para mantenerla, sí. La administración gestionada incluye monitorización 24/7 y respuesta a incidentes.

Nuestra recomendación

Mínimo absoluto: SSH con claves, firewall UFW, fail2ban, actualizaciones automáticas. Esto te protege de la mayoría de ataques.

Para servidores de producción: Todo lo anterior más monitorización activa, alertas por email y auditorías periódicas.

Si manejas datos sensibles: Considera SELinux/AppArmor, 2FA para SSH y un IDS como OSSEC.

Conclusión

Securizar un VPS Linux es cuestión de aplicar las medidas correctas de forma sistemática. No es difícil, pero requiere disciplina.

Las claves: SSH con claves (no contraseñas), firewall restrictivo, fail2ban activo y sistema actualizado. Con esto, tu servidor está mucho más seguro que el 90% de los servidores en internet.

La seguridad no es un estado, es un proceso. Mantén tu servidor actualizado, revisa logs regularmente y adapta tu configuración según aparezcan nuevas amenazas.

¿Quieres un VPS seguro sin complicaciones? Explora los VPS de Avantys con administración gestionada o consulta la guía completa de VPS.

Guías relacionadas

¿Quieres la guía completa con todos los casos de uso?

→ Volver a la guía maestra: Mejor VPS en España 2025