configurar seguridad inicial en un nuevo VPS

Los primeros 10 minutos deciden qué tan seguro es tu servidor

Un VPS recién creado no es seguro. Desde el momento en que tiene una IP pública, los scanners intentan iniciar sesión. La imagen por defecto les ofrece un objetivo fácil: el usuario root suele ser alcanzable, se permiten contraseñas, no hay firewall y nada se parchea automáticamente. La buena noticia es que cerrar todo eso toma unos diez minutos y un puñado de comandos. Este es el runbook que ejecuto en cada servidor nuevo antes de instalar nada.

Sigue los pasos en orden, ya que cada etapa depende de la anterior. Cada paso tiene su propia guía, enlazada durante el proceso; esta página es la ruta rápida que los conecta.

Minuto 1: Actualizar todo

Inicia sesión como root con las credenciales de tu proveedor y actualiza el sistema completamente antes que cualquier otra cosa:

apt update && apt upgrade -y

Un servidor sin parches es el objetivo más fácil, por lo que esto es lo primero. Una vez finalizado, configura las actualizaciones de seguridad automáticas para que el sistema se mantenga parcheado sin que tengas que recordarlo.

Minuto 2: Crear un usuario normal con sudo

No sigas trabajando como root. Crea un usuario para ti y dale permisos sudo:

adduser matt
usermod -aG sudo matt

A partir de aquí, inicia sesión con este usuario y usa sudo para tareas de administración. Trabajar siempre como root significa que cada error y cada compromiso ocurrirán con privilegios ilimitados, que es exactamente lo que usar un usuario sin privilegios busca prevenir.

Minuto 4: Configurar llaves SSH

Las contraseñas se pueden adivinar; las llaves no. En tu propia laptop, si aún no tienes una llave, crea una:

ssh-keygen -t ed25519

Luego copia la parte pública al servidor:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id requiere que el inicio de sesión por contraseña esté activado para el nuevo usuario; si ya está desactivado, copia el ~/.ssh/authorized_keys de root al /home/matt/.ssh/authorized_keys (propiedad de matt), o pega tu llave pública en ese archivo manualmente.

El modelo detrás de este paso (una llave por dispositivo, los permisos que bloquean el inicio de sesión por llave y la revocación de una llave perdida) se explica en conceptos básicos de gestión de llaves SSH.

Cierra la sesión y vuelve a entrar como matt usando la llave, y confirma que funciona antes de pasar al siguiente paso. Bloquear SSH antes de poder entrar con una llave es la forma en que la gente pierde el acceso al servidor.

Minuto 6: Desactivar el inicio de sesión de root y las contraseñas

Ahora que tu llave funciona, cierra las dos puertas que usan los scanners. Usa un archivo de configuración adicional para que las actualizaciones de paquetes no lo sobrescriban. Nómbralo 00- para que se ordene antes de 50-cloud-init.conf, que es el que traen las imágenes cloud de Ubuntu con PasswordAuthentication yes; sshd mantiene el primer valor que lee, por lo que un archivo con orden posterior perdería la configuración silenciosamente:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Luego recarga SSH:

sudo systemctl restart ssh

Luego verifica la configuración que sshd realmente está usando, para que un archivo mal ordenado no te engañe:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Con las contraseñas desactivadas y el acceso de root eliminado, el tráfico constante de fuerza bruta contra tu servidor simplemente no podrá tener éxito. El proceso completo, incluyendo un cambio de puerto opcional, está en SSH hardening on a VPS.

Minuto 8: Activar el firewall

Deniega todo lo entrante por defecto y luego permite solo lo que necesites. Permite SSH antes de activar el firewall o cortarás tu propia conexión:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Añade reglas allow para cualquier servicio que ejecutes, como 80/tcp y 443/tcp para un sitio web. Verifica que tanto IPv4 como IPv6 estén cubiertos, porque un firewall que solo filtra IPv4 deja el lado de IPv6 totalmente abierto. La guía completa está en Firewalls 101 on a VPS.

Minuto 10: Retrasar a los scanners con Fail2ban

Finalmente, añade Fail2ban para expulsar las direcciones que atacan tus puertos:

sudo apt install -y fail2ban

En Ubuntu 24.04, la instalación estándar protege SSH desde el primer arranque. Con el uso de llaves ya requerido, esto es un respaldo que reduce el ruido en los logs y bloquea a los atacantes recurrentes, en lugar de ser tu defensa principal.

Tu checklist

Ese es el runbook. Usa el generador de abajo para marcar cada control y producir una lista personalizada que puedas conservar con el servidor, incluyendo el comando exacto para cada paso:

Repite este proceso en cada servidor nuevo y se convertirá en memoria muscular. Diez minutos ahora te ahorrarán una tarde muy mala tras el compromiso de un servidor.

Una vez que los elementos esenciales estén instalados, automatic security updates on Ubuntu mantendrán el servidor actualizado sin que tengas que volver a iniciar sesión.

FAQ

¿Qué debo hacer primero en un VPS nuevo?

Actualiza el sistema con apt update && apt upgrade -y, luego crea un usuario normal con sudo y deja de trabajar como root. A partir de ahí, configura llaves SSH, desactiva el inicio de sesión de root y la autenticación por contraseña, habilita un firewall de denegación por defecto e instala Fail2ban. Hacerlo en ese orden asegura que cada paso sea seguro sin perder el acceso al servidor.

¿Cómo evito perder el acceso mientras endurezco SSH?

Configura y prueba el inicio de sesión con tu llave SSH antes de desactivar las contraseñas o el acceso de root. Cierra la sesión y vuelve a entrar con la llave para confirmar que funciona, y solo entonces desactiva PasswordAuthentication y PermitRootLogin. Cuando habilites el firewall, permite el puerto 22 antes de ejecutar ufw enable. Si pierdes el acceso, la consola web de tu proveedor te permitirá entrar sin SSH.

¿Realmente necesito todo esto en un servidor pequeño?

Sí, porque a los scanners no les importa qué tan pequeño sea tu servidor. Intentan atacar cada IP pública de la misma manera. El runbook completo toma unos diez minutos y elimina las rutas fáciles: sin acceso de root, sin adivinación de contraseñas, sin nada expuesto que no hayas elegido y con errores conocidos parcheados automáticamente.

¿Cuál es el paso más importante?

SSH solo con llaves y con el acceso de root desactivado. La mayoría de los ataques en un VPS nuevo son intentos automatizados de adivinar la contraseña de root; desactivar ambos hace que esa categoría de ataque sea imposible. El firewall y Fail2ban luego limitan lo que queda expuesto y ralentizan cualquier intento restante.

¿Cómo confirmo que el servidor está realmente protegido?

Verifica tres cosas manualmente antes de confiar en él. Ejecuta sudo ss -tlnp y confirma que solo los puertos que decidiste abrir están escuchando en una dirección pública, sin ningún servicio 0.0.0.0 o [::] que hayas olvidado. Ejecuta sudo ufw status verbose y confirma que la política de entrada por defecto es deny y que las reglas tanto de IPv4 como de (v6) están presentes. Y siempre abre una segunda sesión de SSH antes de cerrar la primera, para que un error en la configuración de SSH no te deje fuera del servidor. Si los tres puntos son correctos, los conceptos básicos están aplicados.