Por qué su VPS es vulnerable desde la entrega
En cuanto se asigna una dirección IP a su servidor, robots automatizados empiezan a escanearla. Shodan, Censys y miles de bots maliciosos catalogan de forma permanente los puertos abiertos en Internet. Un servidor Linux recién instalado expone por defecto el puerto 22 en SSH, con el usuario root accesible desde cualquier dirección IP del mundo. Si su contraseña de root es débil —o si ha reutilizado una contraseña ya comprometida en otras filtraciones de datos—, su servidor puede quedar comprometido en unas horas, incluso en unos minutos. Sin cortafuegos, todos los puertos que abran sus futuras aplicaciones también quedarán accesibles sin restricción. Sin sistema de detección de intrusiones, ninguna alerta le avisará de un ataque de fuerza bruta en curso. Esta guía corrige estos tres problemas fundamentales con herramientas contrastadas, disponibles directamente en los repositorios oficiales de su distribución.
Lo que esta guía pone en marcha
- Usuario no root con sudo — reduce la superficie de ataque al desactivar las conexiones directas como root
- Autenticación por clave SSH — elimina los ataques de fuerza bruta sobre las contraseñas: solo su clave privada da acceso
- Desactivación del acceso root por SSH — aunque la contraseña de root esté comprometida, la conexión directa sigue siendo imposible
- UFW (cortafuegos) — bloquea por defecto todo el tráfico entrante y solo permite los puertos declarados explícitamente
- fail2ban — banea automáticamente las direcciones IP que acumulan intentos de conexión fallidos
- Actualizaciones de seguridad automáticas — los parches críticos se aplican sin intervención manual diaria
- Sincronización del reloj del sistema — garantiza registros coherentes y certificados TLS válidos
Requisitos previos antes de empezar
Antes de seguir esta guía, asegúrese de disponer de todo lo necesario. Una preparación correcta le evitará quedarse bloqueado a mitad de camino, sobre todo en el momento de configurar SSH, donde un error puede dejarle sin acceso al servidor.
Lo que necesita
- Acceso root por SSH operativo — debe poder conectarse con
ssh [email protected]antes de empezar - Ubuntu 22.04 LTS o Debian 12 — esta guía está probada en estas dos distribuciones y los comandos son idénticos
- Un par de claves SSH generado localmente — ejecute
ssh-keygen -t ed25519en su máquina si todavía no lo tiene - Un terminal con dos pestañas abiertas — mantenga siempre una sesión root activa durante la configuración de SSH para evitar cualquier bloqueo
Los 7 pasos del endurecimiento
Actualizar el sistema
Empiece por sincronizar la lista de paquetes y aplicar todos los parches disponibles:
apt update && apt upgrade -y. Reinicie si se ha instalado un nuevo kernel:reboot. Vuelva a conectarse como root tras el reinicio antes de pasar al paso siguiente.Crear un usuario no root con sudo
Cree un nuevo usuario que será su cuenta de trabajo diaria. Sustituya
deploypor el nombre que prefiera:adduser deploy. Siga las indicaciones para definir una contraseña robusta. Añada después este usuario al grupo sudo:usermod -aG sudo deploy. Compruebe que se ha añadido correctamente:groups deploydebe mostrardeploy sudo.Copiar su clave SSH al nuevo usuario
Desde su máquina local, copie su clave pública a la cuenta
deploy:ssh-copy-id [email protected]. Sissh-copy-idno está disponible, cópiela manualmente conectándose por SSH comodeployy ejecute:mkdir -p ~/.ssh && chmod 700 ~/.ssh, pegue su clave pública en~/.ssh/authorized_keysy apliquechmod 600 ~/.ssh/authorized_keys. Pruebe la conexión de inmediato en una pestaña nueva:ssh [email protected]. No cierre la sesión root mientras esa conexión no esté confirmada.Endurecer la configuración de SSH
Edite el archivo de configuración del demonio SSH:
nano /etc/ssh/sshd_config. Modifique o añada estas directivas:PermitRootLogin nopara prohibir el acceso root directo,PasswordAuthentication nopara desactivar la autenticación por contraseña y, opcionalmente,Port 2222para cambiar el puerto de escucha (no olvide abrir ese puerto en UFW antes de reiniciar). Recargue la configuración:systemctl reload sshd. Pruebe de inmediato la conexión con el nuevo usuario desde otro terminal antes de cerrar su sesión actual.Configurar UFW (cortafuegos)
Instale UFW si es necesario:
apt install ufw -y. Defina la política por defecto:ufw default deny incomingyufw default allow outgoing. Autorice los puertos que necesite: si ha cambiado el puerto SSH,ufw allow 2222/tcp; si no,ufw allow 22/tcp. Añada los puertos web:ufw allow 80/tcpyufw allow 443/tcp. Active el cortafuegos:ufw enable. Confirme conYcuando se le pida. Compruebe el estado:ufw status verbose.Instalar y configurar fail2ban
Instale fail2ban:
apt install fail2ban -y. Cree un archivo de configuración local para que sus ajustes no se sobrescriban en las actualizaciones:cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local. Editejail.localpara activar la protección SSH: en la sección[sshd], asegúrese de queenabled = trueestá presente y ajustebantime = 1h,findtime = 10m,maxretry = 5. Reinicie y active el servicio:systemctl enable --now fail2ban. Compruebe que la jail SSH está activa:fail2ban-client status sshd.Activar las actualizaciones de seguridad automáticas
Instale el paquete unattended-upgrades:
apt install unattended-upgrades -y. Lance el asistente de configuración:dpkg-reconfigure -plow unattended-upgradesy respondaYes. Para comprobar que las actualizaciones automáticas de seguridad están realmente activadas, consulte/etc/apt/apt.conf.d/20auto-upgrades: deben aparecer las dos líneasAPT::Periodic::Update-Package-Lists "1";yAPT::Periodic::Unattended-Upgrade "1";. Asegúrese también de que systemd-timesyncd está activo para mantener el reloj en hora:systemctl status systemd-timesyncd.
Consejo crítico: pruebe SIEMPRE la conexión SSH con su nuevo usuario en un segundo terminal ANTES de cerrar su sesión root. Si cierra la sesión root sin haber comprobado que la autenticación por clave funciona para deploy, corre el riesgo de quedarse definitivamente fuera de su servidor. En caso de duda, utilice la consola KVM/VNC disponible en su panel de control ServOrbit.
Ir más lejos tras el endurecimiento inicial
Una vez completados los siete pasos, su servidor es mucho más seguro que en el momento de la entrega. Pero la seguridad es un proceso continuo, no un estado fijo. Varias herramientas complementarias pueden reforzar aún más su postura de seguridad según su contexto. Para los entornos que deben responder a exigencias de cumplimiento (RGPD, PCI-DSS, ISO 27001), instale auditd: apt install auditd -y y después systemctl enable --now auditd. Este demonio registra todas las llamadas al sistema sensibles —ejecución de comandos, modificaciones de archivos, conexiones— y facilita las auditorías regulatorias. Para una protección más avanzada frente a las botnets y los escaneos coordinados, CrowdSec es una excelente alternativa a fail2ban: analiza los comportamientos de forma colaborativa, comparte las reputaciones de IP entre sus usuarios y dispone de paneles de supervisión modernos. Nuestro artículo dedicado detalla su instalación y su configuración en Ubuntu y Debian.
fail2ban vs CrowdSec: ¿cuál elegir?
Desplace la tabla
| Criterio | fail2ban | CrowdSec |
|---|---|---|
| Facilidad de instalación | Muy sencilla (apt) | Sencilla (script oficial) |
| Inteligencia colectiva | No (solo local) | Sí (base compartida) |
| Interfaz de supervisión | Solo CLI | Dashboard web incluido |
| Consumo de recursos | Muy bajo | Bajo o moderado |
| Ideal para | Servidores sencillos, principiantes | Infraestructuras multiservidor, compliance |
Solución de problemas: casos habituales tras el endurecimiento
Incluso con un procedimiento cuidadoso, puede ocurrir que se quede bloqueado o que se encuentre con comportamientos inesperados. Estas son las tres situaciones más frecuentes y cómo resolverlas. Primer caso: se ha quedado fuera por SSH. Conéctese mediante la consola KVM o VNC de su panel ServOrbit, que da acceso directo al servidor con independencia de SSH. Una vez conectado por consola, puede corregir la configuración de sshd, añadir su clave en authorized_keys o restablecer una contraseña. Segundo caso: fail2ban ha baneado su propia dirección IP. Desbanéese desde la consola o desde otra IP: fail2ban-client set sshd unbanip SU_IP. Para evitar que vuelva a ocurrir, añada su IP fija en la sección [DEFAULT] de jail.local: ignoreip = 127.0.0.1/8 SU_IP. Tercer caso: ha cambiado el puerto SSH pero ha olvidado abrirlo en UFW antes de reiniciar sshd. Conéctese por consola, añada la regla que falta ufw allow 2222/tcp y ejecute ufw reload.
Conclusión
En menos de una hora ha transformado un servidor vulnerable en una base sólida: el acceso root por SSH está desactivado, solo las claves criptográficas permiten conectarse, un cortafuegos filtra todo el tráfico no autorizado, fail2ban bloquea automáticamente a los atacantes y los parches de seguridad se aplican sin intervención manual. Estos siete pasos son el mínimo absoluto para cualquier servidor expuesto a Internet. No sustituyen a una securización a nivel de aplicación (HTTPS, cabeceras de seguridad, validación de entradas), pero cierran los vectores de ataque más explotados en los VPS Linux. Recuerde documentarlos en el runbook de su equipo y aplicarlos sistemáticamente a cada nuevo servidor que aprovisione.
