Un VPS recién creado queda expuesto a ataques automatizados a los pocos minutos de estar en línea: esta checklist te guía a través de la primera hora de fortificación que te permite conservarlo.
Todo servidor nuevo empieza su vida con las mismas debilidades: un inicio de sesión root por defecto, una puerta SSH que solo admite contraseña, un firewall completamente abierto y sin parcheo automático. Los bots escanean continuamente todo el espacio IPv4, así que eso de "todavía nadie conoce mi IP" nunca es cierto.
Esta guía es una checklist de fortificación ordenada y lista para copiar y pegar. Sigue los pasos de arriba hacia abajo en una máquina Debian o Ubuntu recién instalada y cerrarás las brechas que los atacantes realmente explotan, no las que solo preocupan al teatro de la seguridad.
Antes de tocar el servidor
Dos decisiones tomadas antes de tu primer inicio de sesión te ahorran horas más adelante. Prepara tu clave SSH y elige un nombre de usuario que no sea root.
- 1
Genera una clave SSH moderna
En tu propia máquina ejecuta ssh-keygen -t ed25519 -C "you@device". Las claves Ed25519 son cortas, rápidas y más seguras que el antiguo estándar RSA-2048.
- 2
Mantén la clave privada fuera del servidor
La mitad privada nunca debe salir de tu portátil. Solo copias el archivo .pub a los servidores. Olvidar esta regla es la forma en que la gente termina teniendo que reaprovisionar desde cero.
- 3
Anota tus credenciales de aprovisionamiento
La mayoría de los proveedores envían por correo una contraseña root temporal o inyectan tu clave durante la creación del servidor. Si se inyectó una clave, puedes pasar directamente a crear un usuario.
Si tu proveedor inyecta tu clave SSH en el momento del despliegue, nunca llegas a tener una ventana de acceso por contraseña — la mayor superficie de ataque desaparece incluso antes de arrancar.
Paso 1 — Parchea todo y mantenlo parcheado
Un kernel u OpenSSL sin parchear es el único fallo que ninguna regla de firewall soluciona. Actualiza antes de configurar cualquier otra cosa.
- Debian/Ubuntu: apt update && apt full-upgrade -y y reinicia si el kernel cambió.
- Activa unattended-upgrades para que los parches de seguridad se apliquen automáticamente: apt install unattended-upgrades && dpkg-reconfigure unattended-upgrades.
- Reinicia en un horario que controles tú — configura Unattended-Upgrade::Automatic-Reboot a una hora de baja actividad en lugar de dejar los kernels a medio aplicar.
Paso 2 — Crea un usuario real y retira el uso de root
Iniciar sesión como root significa que una sola sesión comprometida controla toda la máquina y no deja rastro de auditoría. En su lugar, date de alta una cuenta sudo con nombre propio.
- 1
Añade el usuario
adduser deploy y luego usermod -aG sudo deploy (usa wheel en sistemas de la familia RHEL).
- 2
Instala tu clave para ese usuario
Desde tu portátil: ssh-copy-id deploy@your-server-ip. Esto escribe tu clave pública en ~/.ssh/authorized_keys con los permisos correctos.
- 3
Comprueba antes de cerrar la puerta
Abre una segunda terminal y confirma que puedes hacer ssh deploy@server y ejecutar sudo -v. Nunca desactives root ni las contraseñas hasta que una sesión nueva funcione.
Regla de oro de la fortificación SSH: mantén abierta tu sesión actual y comprueba que el nuevo inicio de sesión funciona en una segunda ventana antes de cambiar cualquier ajuste de autenticación. Este único hábito evita casi todos los bloqueos.
Paso 3 — Fortificación de SSH, la parte más importante
SSH es la puerta principal de todo VPS, y es donde se concentra la mayoría de los intentos automatizados de inicio de sesión. Edita /etc/ssh/sshd_config (o un archivo adicional en /etc/ssh/sshd_config.d/) y configura estas claves.
Aplica los cambios con sshd -t para validar la sintaxis y después systemctl restart ssh. Si sshd -t indica un error, corrígelo antes de reiniciar o podrías dejar caído el demonio.
Cambiar el puerto SSH del 22 a otro es opcional y solo reduce el ruido en los logs — es ofuscación, no seguridad. Una vez que PasswordAuthentication está desactivado, los bots que escanean puertos no tienen nada que adivinar, así que dedica tu esfuerzo a las claves en lugar de a juegos con el puerto.
Paso 4 — Activa un firewall de denegación por defecto
Un demonio SSH fortificado sigue compartiendo la máquina con cualquier otro servicio a la escucha. Un firewall convierte en norma el "cerrado a menos que yo lo abra".
- 1
Establece la base
Con ufw: ufw default deny incoming y ufw default allow outgoing.
- 2
Permite solo lo que sirves
ufw allow OpenSSH, además de ufw allow 80,443/tcp solo si esta máquina realmente sirve tráfico web.
- 3
Activa y verifica
ufw enable y después ufw status verbose. Todo lo que no aparezca en la lista queda ahora inalcanzable desde internet.
Añade la regla del firewall para SSH antes de activar ufw. Activar un firewall de denegación por defecto sin una regla que permita tu propio puerto cortará tu sesión.
Paso 5 — Frena la fuerza bruta con Fail2ban
Incluso con las contraseñas desactivadas, los bots siguen llamando a la puerta e inflando tus logs. Fail2ban bloquea a los reincidentes a nivel de firewall.
- apt install fail2ban — la jail de sshd que trae por defecto funciona sin configuración adicional.
- Copia jail.conf a jail.local y ajusta bantime (por ejemplo, 1h) al alza y maxretry (por ejemplo, 3) a la baja según tu preferencia.
- Comprueba que funciona con fail2ban-client status sshd para ver el número de IPs baneadas.
Paso 6 — Reduce la superficie de ataque
El servicio más seguro es el que no se está ejecutando. Audita lo que está a la escucha y elimina lo que no necesites.
Audita los puertos abiertos
ss -tulpn lista cada socket a la escucha y el proceso que hay detrás. Investiga cualquier cosa que no hayas iniciado deliberadamente.
Elimina paquetes que no usas
Desactiva o desinstala los servicios que no uses — una base de datos o un agente de correo que se quede ejecutándose es pura responsabilidad.
Aísla los servicios
Vincula los demonios internos, como las bases de datos, a 127.0.0.1 para que nunca queden expuestos aunque el firewall falle.
Blinda los permisos
Asegúrate de que ~/.ssh tenga permisos 700 y authorized_keys tenga 600. Unos permisos incorrectos hacen que sshd ignore tu clave silenciosamente.
Paso 7 — Registra, monitoriza y conoce tu línea base
La fortificación no es un evento puntual. Necesitas darte cuenta cuando algo cambia.
- Revisa la actividad de autenticación con journalctl -u ssh o lastb para ver los inicios de sesión fallidos.
- Considera usar auditd para tener un registro a prueba de manipulaciones de las acciones privilegiadas.
- Mantén una copia de seguridad fuera del servidor de /etc y de tus datos, para que una máquina comprometida pueda reconstruirse limpia en lugar de seguir confiando en ella después de los hechos.
Dónde importa el propio proveedor
La fortificación del software protege el sistema operativo, pero el proveedor decide lo que hay debajo — el filtrado de red, el rastro de pago y si una identidad llega a quedar vinculada al servidor. En ChainVPS, todos los planes incluyen filtrado DDoS y ancho de banda no medido, y los servidores se pagan con un saldo prepagado en criptomonedas entre 21 monedas, incluido Monero, sin KYC. Si tu modelo de amenaza incluye no vincular un servidor a tu identidad, nuestros planes de VPS offshore están pensados exactamente para eso.
La ubicación también forma parte de la fortificación: seis de nuestras quince regiones son jurisdicciones de nivel privacidad (NL, CH, RO, IS, MD, LU). Combinar un sistema operativo fortificado con un servidor dedicado offshore mantiene ajustadas tanto la superficie de software como la legal.
La checklist de una hora, en resumen
- Actualización completa del sistema + parches de seguridad automáticos activados
- Usuario sudo con nombre propio creado, clave instalada, inicio de sesión probado
- Inicio de sesión SSH como root y autenticación por contraseña desactivados
- Configuración de SSH validada con sshd -t y recargada
- Firewall de denegación por defecto activo, solo los puertos necesarios abiertos
- Fail2ban ejecutándose en la jail de sshd
- Puertos abiertos auditados, servicios sin uso eliminados
- Copia de seguridad fuera del servidor y revisión de logs implementadas
¿Debería cambiar el puerto SSH a uno distinto del 22?
Es opcional y solo reduce el ruido en los logs, no el riesgo real. Una vez que la autenticación por contraseña está desactivada y se exigen claves, cambiar el puerto añade ofuscación en lugar de seguridad — prioriza primero la desactivación de las contraseñas.
¿Es seguro desactivar la autenticación por contraseña si solo tengo una clave?
Sí, siempre que hayas probado el inicio de sesión con la clave en una sesión aparte y conserves una copia de seguridad de la clave privada. Muchos proveedores también ofrecen una consola web o un modo de recuperación, así que nunca te quedas realmente sin acceso al hardware.
¿Sigo necesitando un firewall si SSH es el único servicio?
Sí. Un firewall de denegación por defecto te protege de servicios que olvidaste que instalaste y de cualquier cosa que un futuro paquete empiece a escuchar silenciosamente. No cuesta nada y elimina sorpresas.
¿Con qué frecuencia debería revisar la fortificación?
Las actualizaciones de seguridad automáticas se encargan del trabajo diario, pero revisa los puertos a la escucha y los logs de autenticación después de cualquier instalación importante de software y, como mínimo, una vez al mes. Trata una línea base fortificada como algo que verificas, no como algo que configuras una vez y olvidas.
