Configuración de VPS: Seguridad Base

Elber — Mon, 02 Feb 2026 00:29:47 +0000

Contexto y Objetivos

El propósito de este documento es establecer una línea base de seguridad (hardening) para cualquier instancia VPS recién aprovisionada. Independientemente del proveedor (DigitalOcean, AWS, etc.), la configuración por defecto ("defaults") suele priorizar la compatibilidad sobre la seguridad, lo cual es inaceptable para un entorno de producción.

Este tutorial abarca múltiples conceptos de forma ejecutiva para lograr un despliegue rápido y seguro. Más adelante publicaré artículos técnicos detallados desglosando la arquitectura y configuración profunda de cada herramienta (SSH, Fail2Ban, UFW, etc.).

Vamos a cerrar vectores de ataque comunes, establecer políticas de acceso estricto y configurar herramientas de monitoreo activo antes de siquiera pensar en desplegar aplicaciones.

1. Actualización y Sincronización

1.1. Actualización de Paquetes

No tiene sentido configurar seguridad sobre dependencias obsoletas. Actualizamos los repositorios y parches del sistema operativo inmediatamente.

sudo apt update && sudo apt upgrade -y

1.2. Zona Horaria y NTP

Para un debugging efectivo, los logs deben estar sincronizados con tu tiempo local. Correlacionar incidentes con logs en UTC desfasados es ineficiente.

# Configurar Timezone (Ej: Venezuela)
sudo timedatectl set-timezone America/Caracas

# Verificar consistencia
timedatectl

Aseguramos que el demonio de sincronización de tiempo esté activo para evitar drifts que afecten la validación de certificados SSL o TOTP.

sudo timedatectl set-ntp on

2. Gestión de Identidad y Accesos (IAM)

El uso directo de root es una mala práctica crítica. Vamos a crear un usuario operativo y bloquear el acceso administrativo directo.

2.1. Usuario Sudoer

Creamos un usuario con capacidad de escalamiento de privilegios (sudo) para tareas administrativas.

# Reemplaza 'deployer' por tu usuario estándar
adduser deployer
usermod -aG sudo deployer

Validación: Antes de continuar, loguéate como el nuevo usuario (su - deployer) y verifica que puedes ejecutar comandos con privilegios (sudo whoami). Si responde root, procede.

3. Configuración del Servicio SSH

El puerto 22 es el objetivo principal de los scanners automatizados. Vamos a cambiar la configuración por defecto para mitigar ataques de fuerza bruta y deshabilitar autenticación por contraseña.

3.1. Llaves SSH (Algoritmo Ed25519)

Olvida RSA. Usaremos Ed25519 por su performance y menor tamaño de llave. Si ya dispones de un par de llaves generado bajo este algoritmo, este paso es opcional; puedes reutilizar tu llave pública existente.

En tu máquina local:

ssh-keygen -t ed25519 -C "admin@infrastructure"
cat ~/.ssh/id_ed25519.pub

3.2. Instalación de la Llave (En el VPS)

ADVERTENCIA CRÍTICA: No realices estos pasos como usuario root. Debes estar logueado con el usuario creado en el paso 2.1 (su - deployer). Si instalas la llave en el directorio de root, no podrás acceder con tu usuario operativo tras deshabilitar las contraseñas, lo que resultará en un bloqueo total del acceso.

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys # Pega tu llave pública aquí
chmod 600 ~/.ssh/authorized_keys

3.3. Configuración del Daemon (sshd_config)

Una vez instalada la llave en el usuario operativo, procedemos a restringir el daemon. Esto se hace con privilegios de superusuario:

sudo nano /etc/ssh/sshd_config

Dentro del archivo, localiza y modifica (o añade al final) las siguientes directivas. Asegúrate de que no tengan el símbolo # al inicio:

Port 2965                   # Security by obscurity (filtra el ruido de bots básicos)
PermitRootLogin no          # Bloqueo total a root
PasswordAuthentication no   # Solo llaves públicas
PubkeyAuthentication yes
X11Forwarding no            # Reducir superficie de ataque

Reiniciamos el servicio para aplicar cambios:

sudo systemctl restart ssh

Nota: A partir de este punto, el acceso es ssh -p 2965 deployer@<IP>.

4. Seguridad Activa y Firewall

4.1. Fail2Ban (Intrusion Prevention)

Configuramos Fail2Ban para monitorear logs de autenticación y banear IPs que presenten comportamiento anómalo (fuerza bruta).

sudo apt install fail2ban -y

Creamos una configuración local para proteger nuestro puerto SSH personalizado en /etc/fail2ban/jail.d/sshd.local:

[sshd]
enabled = true
port = 2965
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 600
bantime = 3600  # 1 hora de ban inicial
banaction = ufw

Aplicamos y verificamos:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

4.2. Firewall (UFW)

Implementamos una política de "Deny All" por defecto. Solo abrimos lo estrictamente necesario.

# 1. Resetear reglas previas
sudo ufw --force reset

# 2. Políticas por defecto
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 3. Allow SSH (CRÍTICO: Usar el puerto custom configurado)
sudo ufw allow 2965/tcp

# 4. Habilitar
sudo ufw enable

Validación final:

sudo ufw status numbered

Próximos Pasos

Con esto tenemos una infraestructura base segura. El servidor está blindado contra ataques básicos de diccionario y escaneos de puertos estándar.

DEV Community: Elber