Cómo proteger un VPS nuevo: los primeros diez minutos

Un servidor nuevo está en su punto más expuesto justo cuando recibe una dirección IP. Los escáneres automatizados recorren continuamente todo el espacio IPv4, así que los primeros intentos de inicio de sesión contra una máquina desplegada hace un minuto suelen llegar antes de que termines de leer su mensaje de bienvenida. Nada de eso va dirigido a ti — es ruido de fondo, y es la razón por la que un servidor sin endurecer con una contraseña en root queda comprometido en cuestión de horas y no de meses. La buena noticia es que cerrarlo es un trabajo corto: diez minutos de pasos ordenados eliminan prácticamente todo el riesgo oportunista. Esta guía cubre esa lista de verificación, el orden que evita que te quedes fuera de tu propia máquina, y una cosa que la mayoría de los tutoriales de endurecimiento nunca mencionan — los datos personales que una configuración por defecto anota silenciosamente en una máquina que alquilaste precisamente para que no quedara vinculada a ti.

De qué te protege realmente el endurecimiento

Endurecer un servidor merece la pena precisamente porque sus beneficios son concretos y reales, no difusos. Tener claro dónde está el límite evita una falsa sensación de seguridad en las áreas que no cubre.

• Elimina por completo al atacante oportunista. Los bots de credential stuffing, la fuerza bruta contra SSH y los rastreos en busca de paneles de administración expuestos fracasan frente a una autenticación solo por clave y un firewall que deniega todo por defecto.
• Limita el alcance del daño cuando algo que ejecutas tiene un fallo. Un servicio enlazado a localhost detrás de un puerto cerrado no puede alcanzarlo un desconocido, ni siquiera el día en que se publica su CVE.
• Reduce el coste de un error. Usuarios sin privilegios, claves separadas y parcheo automático hacen que una sola mala decisión no entregue toda la máquina.
• No oculta el servidor a tu proveedor. Cualquiera con acceso al hipervisor puede en principio leer la memoria de una máquina en marcha — una cuestión sobre a quién le alquilas, no sobre tus reglas de firewall.
• No te hace anónimo. El endurecimiento protege la máquina; que esa máquina quede vinculada a tu nombre se decide en el registro y en el pago, mucho antes de que inicies sesión por primera vez.

Esa última distinción es la que la gente suele invertir. Un servidor perfectamente endurecido comprado con una tarjeta de crédito a tu nombre legal sigue siendo un servidor a tu nombre legal. Las dos capas son complementarias: el hosting sin KYC y un saldo financiado en criptomonedas deciden a quién pertenece la máquina sobre el papel, y los diez minutos siguientes deciden quién puede entrar en ella.

El orden que evita quedarte fuera

Casi todas las historias de terror sobre endurecimiento son la misma historia: alguien desactivó la autenticación por contraseña antes de confirmar que su clave funcionaba, o activó un firewall cuyas reglas no incluían SSH, y se quedó fuera de una máquina a la que ya no puede acceder. El orden de los pasos existe precisamente para que eso sea imposible. Instala primero la clave y comprueba que funciona en una segunda ventana. Solo entonces desactiva las contraseñas. Añade la regla de firewall para SSH antes de activar el firewall, nunca después.

También conviene saber cuál es tu vía de recuperación antes de necesitarla. Un VPS al que solo puedes acceder por SSH tiene exactamente una puerta, así que la consola del panel de tu proveedor es el recurso que convierte un bloqueo en una molestia en lugar de una reinstalación completa. Comprueba que puedes abrirla mientras todo sigue funcionando.

Paso a paso: los primeros diez minutos en una máquina nueva

1. 01Actualiza el índice de paquetes y los paquetes instaladosUna imagen recién creada es una foto fija del momento en que se construyó. Ponerla al día es la acción de mayor valor de toda la lista, y lleva menos de un minuto.
2. 02Crea un usuario sin privilegios con sudoTrabajar todo el tiempo como root significa que cada error de tecleo y cada proceso se ejecutan con autoridad total. Crea un usuario normal, añádelo al grupo sudo o wheel, y utiliza ese usuario.
3. 03Copia tu clave pública a ese usuarioGenera una clave ed25519 en tu propia máquina si no tienes una, y luego envía la mitad pública con ssh-copy-id. La clave privada nunca sale de tu portátil.
4. 04Abre una segunda terminal y confirma que el inicio de sesión con clave funcionaNo te saltes este paso. Inicia sesión como el nuevo usuario con la clave, en una ventana nueva, antes de cambiar nada relacionado con la autenticación.
5. 05Desactiva la autenticación por contraseña y el login de rootConfigura PasswordAuthentication no y PermitRootLogin prohibit-password, y luego recarga sshd. La fuerza bruta contra la máquina ya no tiene nada que adivinar.
6. 06Activa un firewall que deniega todo por defecto, con SSH permitidoDeniega todo el tráfico entrante, permite tu puerto SSH, y actívalo. Añade después, uno a uno, los puertos que necesiten tus propios servicios.
7. 07Activa las actualizaciones de seguridad automáticasunattended-upgrades en Debian y Ubuntu, dnf-automatic en la familia RHEL. Esto es lo que mantiene la máquina a salvo en el sexto mes, cuando ya has dejado de prestarle atención.
8. 08Lista lo que está escuchando y cierra lo que no debería estarloUn solo ss -tulpn te muestra cada socket abierto. Cualquier cosa que no pusieras ahí deliberadamente debería eliminarse o enlazarse a localhost.

SSH: solo claves, y los ajustes que importan

La autenticación por clave pública es todo el endurecimiento de SSH. Una vez desactivadas las contraseñas, un atacante necesita una clave privada que no tiene, y ninguna cantidad de intentos produce una. Genera claves ed25519 — son cortas, rápidas, y el estándar moderno — y protege la clave con una frase de contraseña, para que un portátil robado no se convierta en un servidor robado. Todo lo demás en sshd_config es un ajuste fino sobre esa única decisión.

• PasswordAuthentication no — el ajuste que acaba con la fuerza bruta. Verifica primero que tu clave funciona, en una segunda sesión.
• PermitRootLogin prohibit-password — a root todavía se puede llegar por clave para recuperación, pero nunca por contraseña. Ponlo en no en cuanto tu usuario sudo esté probado.
• AllowUsers o AllowGroups — una lista blanca explícita de quién puede iniciar sesión, de modo que la cuenta de servicio creada por algún paquete nunca pueda ser un punto de entrada por SSH.
• KbdInteractiveAuthentication no — cierra la otra vía interactiva que en algunas distribuciones puede reactivar silenciosamente las peticiones de contraseña.
• Una segunda clave para un segundo dispositivo, en lugar de copiar una misma clave privada de un lado a otro. Perder un teléfono debería significar borrar una línea de authorized_keys, no rotarlo todo.
• Mover SSH fuera del puerto 22 reduce drásticamente el volumen de tus registros, pero trátalo como una reducción de ruido y no como seguridad real — no cambia nada para quien realmente esté mirando tu IP.

Si quieres ir más allá de las claves, la disposición más sólida es no exponer SSH públicamente en absoluto: coloca la máquina detrás de un túnel WireGuard y filtra el puerto 22 en el firewall para que solo acepte conexiones desde la dirección del túnel. Eso convierte tu demonio SSH en algo que internet no puede ver, lo cual es un mejor resultado que cualquier cantidad de endurecimiento de configuración sobre uno expuesto.

El firewall: denegar por defecto, y abrir exactamente lo que uses

Un firewall solo tiene sentido si su comportamiento por defecto es rechazar. Permitir todo y luego bloquear los puertos conocidos como malos es hacerlo al revés: acabas protegiendo los servicios que recordabas y exponiendo los que olvidaste. Deniega todo el tráfico entrante, permite el saliente, y luego abre puertos individuales a medida que despliegas lo que los necesita. El Linux moderno usa nftables por debajo, y ufw o firewalld son interfaces perfectamente válidas para ello — la herramienta importa mucho menos que el comportamiento por defecto.

• Permite SSH antes de activar el firewall, no después. Es la segunda forma más común de quedarte fuera de tu propia máquina.
• Abre solo los puertos que un servicio realmente necesita desde fuera. Un servidor web necesita el 80 y el 443; una base de datos casi nunca necesita nada.
• Enlaza los servicios de uso exclusivamente local a 127.0.0.1 en lugar de a 0.0.0.0. Un puerto cerrado y un servicio que nunca escucha públicamente son dos protecciones independientes, y quieres las dos.
• Escribe reglas para IPv6 además de para IPv4. Un conjunto de reglas que solo cubre v4 en una máquina de doble pila deja el mismo servicio completamente abierto en su dirección v6.
• Restringe los puertos de administración por dirección de origen siempre que puedas. Si la administración siempre llega desde un único extremo VPN, especifícalo en la regla.
• Vuelve a revisar las reglas después de añadir un servicio. Los puertos abiertos para algo que ya has eliminado son la acumulación silenciosa que deshace un buen comienzo.

Algunas cargas de trabajo invierten la lógica y necesitan a propósito un puerto completamente abierto — un repetidor Tor tiene que aceptar conexiones desde cualquier lugar, y un nodo completo de Bitcoin solo sirve a otros peers si el 8333 es alcanzable. Eso está bien. La regla no es «no abrir nada», es «abrir deliberadamente», y un servicio diseñado para ser público es una elección deliberada.

fail2ban, y por qué importa menos de lo que crees

fail2ban vigila tus registros y banea las direcciones que fallan la autenticación repetidamente. Es genuinamente útil, pero conviene ser honesto sobre lo que hace una vez que ya has desactivado la autenticación por contraseña: llegados a ese punto, nadie puede tener éxito adivinando, así que fail2ban ya no está impidiendo una intrusión. Lo que sí impide son miles de líneas de registro inútiles al día, la CPU que consumen esos intentos de conexión, y el riesgo de que un incidente real quede enterrado en el ruido que dejaste de leer hace meses.

Aun así merece los diez segundos que lleva configurarlo, y se vuelve genuinamente protector en cuanto ejecutas algo que sí acepta contraseña — el login de una aplicación web, un servidor de correo, un panel de control. Apúntalo a esos registros y no solo a sshd. Fija la ventana de baneo en horas y no en minutos, y añade tu propia dirección a la lista de exclusión para que una contraseña mal tecleada no te deje fuera de tu propia máquina.

Actualizaciones que no tienes que recordar

La amenaza realista para un servidor bien configurado no es alguien venciendo tus claves SSH. Es una vulnerabilidad publicada para algo que instalaste y olvidaste, explotada por un escáner tres días después mientras hacías otra cosa. Las actualizaciones de seguridad automáticas son la respuesta, y en Debian o Ubuntu eso es unattended-upgrades configurado para instalar el repositorio de seguridad; en Fedora, Rocky o Alma es dnf-automatic. Actívalo durante los primeros diez minutos y la máquina se sigue parcheando sola mucho después de que hayas dejado de prestarle atención.

Las actualizaciones del kernel y de libc son la excepción que todavía te necesita: solo surten efecto después de un reinicio, así que un servidor que lleva cuatrocientos días activo casi con toda seguridad está ejecutando código que se parcheó en disco hace un año. needrestart, en Debian, te dirá qué servicios se están ejecutando contra bibliotecas ya eliminadas, y una ventana de reinicio programada — aunque sea mensual — es la diferencia entre parches instalados y parches aplicados. Cualquier cosa que ejecutes debería sobrevivir de todas formas a un reinicio inesperado; si no lo hace, eso es un problema aparte que merece la pena solucionar.

Las fugas de identidad que el endurecimiento pasa por alto

Esta es la sección que importa si elegiste a propósito un proveedor offshore y sin KYC. Una guía de endurecimiento estándar está escrita para el servidor de una empresa cuyo propietario es de dominio público, así que nunca se pregunta qué anota sobre ti la configuración por defecto. En una máquina que alquilaste de forma anónima, varios de esos valores por defecto vuelven a vincular tu nombre a ella sin que te des cuenta.

• Tu clave pública SSH lleva un comentario — por defecto, tu nombre de usuario local y el nombre de host de tu portátil, algo como alex@alex-macbook — y ese comentario se guarda tal cual en authorized_keys en el servidor. Defínelo con el flag -C al generar la clave, o edita la línea después de copiarla.
• El nombre de host que eliges para el servidor acaba en los registros, en las cabeceras de correo, en la salida de monitorización y a veces en los banners de los servicios. Un nombre de host genérico no revela nada; tu nombre o el de tu empresa sí.
• La zona horaria del sistema. Las imágenes en la nube usan UTC por defecto, lo cual no le dice nada a nadie. Configurarla a tu zona local acota dónde estás, y a partir de ahí las marcas de tiempo de cada registro confirman tu horario de trabajo.
• La configuración de Git copiada a la máquina, que lleva el nombre y la dirección de correo con los que haces commit. Lo mismo ocurre con los archivos de historial de shell, los dotfiles sincronizados desde tu estación de trabajo, y cualquier credencial cacheada durante una prueba hecha con prisas.
• La dirección de correo que le das a Let's Encrypt al emitir un certificado, que pasa a formar parte de un registro público de ese certificado. Usa una dirección que no esté ligada a tu identidad.
• Los banners de versión del servidor web y las cabeceras X-Powered-By, además de cualquier agente de analítica, de reporte de fallos o de monitorización de un proveedor que llame a casa desde la máquina con un identificador de cuenta asociado.

Conviene mantener las capas separadas y claras. El endurecimiento mantiene a los desconocidos fuera de la máquina. Estos detalles evitan que la máquina hable de ti a quien ya la esté mirando. Y la capa de pago decide si alguna vez hubo un nombre que encontrar — un tema tratado con honestidad en si comprar un VPS con Bitcoin es realmente anónimo, y llevado más lejos por recargar en Monero. Cada capa falla por sí sola; juntas, resisten.

Copias de seguridad: lo que el endurecimiento no hace por ti

Ninguna regla de firewall protege contra una base de datos borrada, un disco que falla o un cambio de configuración que en su momento pareció razonable. Las copias de seguridad son el único control que te recupera de los errores que cometes tú mismo, que es estadísticamente la forma más probable de perder datos en una máquina bien protegida. Cífralas antes de que salgan del servidor, guarda al menos una copia en algún sitio al que el propio servidor no pueda llegar, y prográmalas para que se ejecuten según un calendario y no cuando te acuerdes.

Ese último punto importa más de lo que parece: un proceso de copia de seguridad que el servidor puede sobrescribir es una copia que cualquier cosa con root en el servidor puede destruir. Enviar los archivos cifrados a un servidor de almacenamiento separado — o extraerlos desde allí, de modo que las credenciales vivan fuera de la máquina que se está respaldando — te da una copia que sobrevive a la máquina. Y haz la restauración una vez, a propósito, mientras no haya ningún problema. Una copia de seguridad no probada es una hipótesis, no una red de seguridad.

Errores que deshacen el trabajo en silencio

• Desactivar la autenticación por contraseña antes de probar la clave, y descubrir el error desde un portátil que ya no puede iniciar sesión.
• Activar el firewall antes de permitir SSH — el mismo bloqueo, alcanzado desde la dirección contraria.
• Escribir reglas solo para IPv4, y dejar cada servicio alcanzable en la dirección IPv6 de la máquina.
• Endurecer todo cuidadosamente el primer día y luego instalar un panel de control, una base de datos y un stack de monitorización que abren cada uno su propio puerto sin que se lo pidas.
• Ejecutarlo todo como root porque es un sudo menos que escribir, de modo que el primer fallo en cualquier cosa se convierte en un compromiso total.
• Tratar fail2ban como un sustituto de las claves, lo cual deja en marcha un juego de adivinar contraseñas que simplemente es más lento.
• Asumir que un servidor alquilado se puede hacer privado frente a su proveedor cifrando el disco — el cifrado completo de disco protege una unidad robada, no una máquina en marcha.
• No reiniciar nunca, de modo que meses de parches de kernel instalados quedan en el disco mientras el kernel antiguo sigue en ejecución.

Nada de esto es difícil ni lleva mucho tiempo. Hazlo en orden, comprueba cada paso desde una segunda terminal antes de continuar, y la máquina que desplegaste hace unos minutos deja de ser una oportunidad para cualquiera que esté rastreando el espacio de direcciones. Después despliega lo que realmente viniste a poner en marcha — un sitio web, un nodo, un túnel, un endpoint de modelo privado — sobre una base que puedas entender.