Qué hacer en los primeros 10 minutos de un VPS

Los primeros 10 minutos determinan la seguridad del servidor

Un VPS recién creado no es seguro. Desde el momento en que tiene una IP pública, los escáneres intentan iniciar sesión. Además, la imagen predeterminada ofrece un objetivo amplio: root suele estar accesible, las contraseñas suelen estar permitidas, no hay firewall y no se instala ningún parche mediante una programación periódica. La buena noticia es que cerrar todos esos puntos requiere unos diez minutos y unos pocos comandos. Este es el procedimiento que aplico en cada servidor nuevo antes de instalar nada en él.

Siga los pasos en orden, porque cada uno depende de los anteriores. Cada paso tiene su propia guía, enlazada en el punto correspondiente. Esta página es la ruta rápida que los reúne.

Minuto 1: Actualizar todo

Inicie sesión como root con las credenciales que le proporcionó su proveedor y actualice por completo el sistema antes de hacer cualquier otra cosa:

apt update && apt upgrade -y

Un sistema sin parches es el objetivo más fácil, por lo que este paso es prioritario. Cuando termine, configure las actualizaciones de seguridad automáticas para mantenerlo actualizado sin tener que recordarlo.

Minuto 2: Cree un usuario normal con sudo

No siga trabajando como root. Cree un usuario para usted y asígnele sudo:

adduser matt
usermod -aG sudo matt

A partir de este momento, inicie sesión con este usuario y use sudo para las tareas administrativas. Ejecutar todo el tiempo como root significa que cada error y cada intrusión se producen con privilegios ilimitados, que es precisamente lo que ejecutar como un usuario sin privilegios evita.

Minuto 4: Configure las claves SSH

Las contraseñas se pueden adivinar; las claves no. En su propio portátil, si todavía no tiene una clave, cree una:

ssh-keygen -t ed25519

Después, copie la parte pública al servidor:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id necesita que el inicio de sesión mediante contraseña esté activado para el usuario nuevo; si ya está desactivado, copie el ~/.ssh/authorized_keys de root en /home/matt/.ssh/authorized_keys (propiedad de matt), o pegue manualmente su clave pública en ese archivo.

El modelo de este paso, una clave por dispositivo, los permisos que impiden iniciar sesión con una clave y la revocación de una clave perdida se explican en Conceptos básicos de la gestión de claves SSH.

Cierre la sesión y vuelva a iniciarla como matt usando la clave. Confirme que funciona antes de continuar con el paso siguiente. Restringir SSH antes de poder acceder con una clave es una forma de quedarse sin acceso. Si ese inicio de sesión devuelve Permission denied (publickey), resuélvalo ahora en lugar de volver a usar la contraseña, porque ese mensaje abarca cinco fallos diferentes y la salida de ssh -v indica cuál de ellos tiene realmente.

Minuto 6: Desactive el acceso de root y las contraseñas

Ahora que la clave funciona, cierre las dos puertas en las que se basan los escáneres. Use un archivo drop-in para que las actualizaciones de paquetes no lo sobrescriban. Llámelo 00- para que se ordene antes que 50-cloud-init.conf, que las imágenes cloud de Ubuntu incluyen con PasswordAuthentication yes; sshd conserva el primer valor que lee, por lo que un archivo que se ordene después perdería el ajuste de forma silenciosa:

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

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

A continuación, vuelva a cargar SSH:

sudo systemctl restart ssh

Después, compruebe los ajustes que sshd utiliza realmente para que un drop-in ignorado no le dé una falsa seguridad:

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 su servidor ya no puede tener éxito. La explicación completa, incluido un cambio de puerto opcional, está en Endurecimiento de SSH en un VPS.

Minuto 8: Active el firewall

Deniegue por defecto todo el tráfico entrante y permita sólo lo necesario. Permita SSH antes de activarlo o se desconectará:

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

Añada reglas allow para cada servicio que realmente ejecute, como 80/tcp y 443/tcp para un sitio web. Si una nueva sesión SSH deja de conectarse después de esto, lea el error antes de cambiar nada, porque un rechazo significa que sshd respondió y un tiempo de espera agotado suele indicar que el firewall descartó el paquete. Compruebe que estén cubiertos IPv4 e IPv6, porque un firewall que sólo filtra IPv4 deja el lado IPv6 completamente expuesto. El tutorial completo está en Firewalls 101 en un VPS. Estos comandos ufw presuponen Ubuntu o Debian. En un equipo Rocky o AlmaLinux, el objetivo de denegar todo por defecto es el mismo, pero la herramienta es firewalld. En ese caso, siga la versión de este paso para firewalld.

Minuto 10: ralentice los escáneres con Fail2ban

Por último, añada Fail2ban para expulsar las direcciones que saturan los puertos:

sudo apt install -y fail2ban

En Ubuntu 24.04, la instalación predeterminada protege SSH desde el primer arranque. Como las claves ya son obligatorias, esto actúa como una medida de respaldo que reduce el ruido de los registros y bloquea a los atacantes reincidentes, en lugar de ser su defensa principal.

Tu lista de comprobación

Ese es el procedimiento operativo. Usa el generador siguiente para marcar cada control y crear una lista de comprobación personalizada que puedas conservar con el servidor, incluido el comando exacto de cada paso:

Repásala una vez con cada servidor nuevo y todo se convertirá en un procedimiento rutinario. Diez minutos ahora evitan la tarde muy complicada que sigue a la intrusión en un servidor.

Cuando los elementos esenciales estén configurados, las actualizaciones de seguridad automáticas en Ubuntu mantienen el servidor actualizado sin que tengas que volver a iniciar sesión. Cada servicio que añadas después necesita su propia revisión, y los puntos débiles cambian: con un almacén de contraseñas autoalojado, el servidor nunca contiene texto sin cifrar, por lo que riesgos reales de Vaultwarden son el token de administración y el archivo de copia de seguridad.

FAQ

¿Qué debo hacer primero en un VPS nuevo?

Actualice el sistema con apt update && apt upgrade -y. Después, cree un usuario normal con sudo y deje de trabajar como root. A continuación, configure las claves SSH, deshabilite el inicio de sesión de root y la autenticación mediante contraseña, active un firewall con denegación predeterminada e instale Fail2ban. Este orden permite aplicar cada paso sin bloquear el acceso.

¿Cómo evito bloquearme mientras refuerzo SSH?

Configure y pruebe el inicio de sesión mediante clave SSH antes de deshabilitar las contraseñas o root. Cierre la sesión y vuelva a iniciarla con la clave para confirmar que funciona. Solo después desactive PasswordAuthentication y PermitRootLogin. Al activar el firewall, permita el puerto 22 antes de ejecutar ufw enable. Si pierde el acceso, la consola web del proveedor le permitirá recuperarlo sin SSH.

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

Sí, porque los escáneres no tienen en cuenta el tamaño del servidor. Prueban todas las IP públicas de la misma forma. Todo el procedimiento tarda unos diez minutos y elimina las vías de acceso más sencillas: sin inicio de sesión de root, sin intentos de adivinar contraseñas, sin servicios expuestos que no haya elegido y con las vulnerabilidades conocidas corregidas automáticamente.

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

Usar SSH solo con claves y deshabilitar el inicio de sesión de root. La mayoría de los ataques contra un VPS recién creado son intentos automatizados de adivinar la contraseña de root. Deshabilitar ambas opciones elimina por completo esa categoría de ataque. El firewall y Fail2ban limitan después la exposición y ralentizan los ataques restantes.

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

Compruebe manualmente tres aspectos antes de confiar en la configuración. Ejecute sudo ss -tlnp y confirme que solo escuchan en una dirección pública los puertos que pretendía abrir, sin ningún servicio 0.0.0.0 o [::] que hubiera olvidado. Ejecute sudo ufw status verbose y confirme que la política de entrada predeterminada es deny y que están presentes tanto las reglas normales como las reglas (v6). Abra siempre una segunda sesión SSH antes de cerrar la primera. Así, un error en la configuración de SSH no podrá bloquear el acceso al servidor. Si los tres aspectos son correctos, la configuración básica está aplicada.