Seguridad de un VPS: los 10 primeros ajustes
Le mostramos, en el orden correcto y con comandos que funcionan, los ajustes de SSH, cortafuegos, fail2ban y actualizaciones de un servidor virtual recién creado, junto con los errores más comunes.
Aurora YazılımEquipo editorial
6 min de lectura
Lo primero para la seguridad de un VPS es actualizar el sistema, crear un usuario con permisos sudo en lugar de usar root y configurar el acceso con clave SSH. Después se desactiva el acceso por SSH de root y con contraseña, se abren en el cortafuegos solo los puertos necesarios, se instala fail2ban, se activan las actualizaciones de seguridad automáticas y se planifica una copia de seguridad periódica.
Por dónde empezar con la seguridad de un VPS
Un servidor virtual recién creado es objetivo de escáneres automáticos desde el momento en que se conecta a internet. Esos bots no apuntan a una empresa concreta, sino que prueban cualquier máquina con un puerto SSH abierto y una contraseña débil. Es normal que en los registros del servidor aparezcan miles de intentos de acceso incluso en las primeras horas.
Por eso la seguridad de un VPS empieza con unos pocos ajustes básicos en la primera hora tras la instalación. Los diez pasos siguientes están escritos para servidores basados en Ubuntu y Debian; en otras distribuciones los nombres del gestor de paquetes y de los servicios cambian, pero la lógica es la misma.
Si la administración de servidores es un terreno nuevo para usted, o si gestiona su sitio con un equipo de software, deje claro desde el principio quién es responsable de estos pasos. Los ajustes de seguridad no son algo que se hace una vez y se olvida, sino un proceso que requiere mantenimiento periódico.
Lo que debe saber antes de empezar
Antes de pasar a la instalación debe tener a mano lo siguiente: la dirección IP del servidor, el primer acceso root o de administrador que le da el proveedor y un terminal en su propio ordenador. En Windows 10 y 11, el cliente OpenSSH viene integrado en PowerShell; en macOS y Linux basta con el Terminal.
Avanzar guardando los comandos en un archivo de notas también es un buen hábito. Saber qué ajuste cambió y cuándo facilita encontrar la causa si más adelante surge un problema y le permite repetir la misma configuración en un segundo servidor. Si se atasca en algún punto durante la instalación, puede consultar a nuestro equipo desde la página de contacto.
Ajustes de sistema y usuarios
Los dos primeros pasos consisten en limpiar el servidor de vulnerabilidades conocidas y hacer el trabajo diario con una cuenta distinta de root.
1. Actualice el sistema
La imagen preparada del proveedor puede haberse creado hace meses. Lo primero es renovar todos los paquetes con los últimos parches de seguridad. Si llega una actualización del kernel, reinicie el servidor.
sudo apt update && sudo apt upgrade -y
sudo reboot2. Cree un usuario con permisos sudo
Trabajar con la cuenta root significa que un solo comando erróneo puede afectar a todo el sistema. Cree un usuario propio y añádalo al grupo sudo; use los privilegios de administrador solo cuando sea necesario.
sudo adduser yonetici
sudo usermod -aG sudo yoneticiSeguridad de SSH
SSH es la puerta de entrada del servidor. Para la seguridad de SSH, los dos pasos más eficaces son usar claves en lugar de contraseñas y desactivar el acceso de root.
3. Configure el acceso con clave SSH
Genere un par de claves en su propio ordenador y copie la clave pública al servidor. En macOS y Linux, el comando ssh-copy-id lo hace en un solo paso; en Windows puede transferir la clave pública al servidor con PowerShell. Ponerle una contraseña (passphrase) a la clave le ofrece una protección adicional incluso si su ordenador cae en manos ajenas.
ssh-keygen -t ed25519
ssh-copy-id yonetici@SUNUCU_IPssh-keygen -t ed25519
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh yonetici@SUNUCU_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"4. Desactive el acceso de root y con contraseña
Una vez que haya comprobado en un segundo terminal que el acceso con clave funciona, refuerce la configuración de SSH. Probar la configuración antes del cambio evita que una línea errónea detenga el servicio.
Atención: en algunas imágenes de nube, los archivos adicionales de la carpeta /etc/ssh/sshd_config.d/ pueden volver a habilitar el acceso con contraseña. Después de aplicar el ajuste, revise también esa carpeta.
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yessudo sshd -t
sudo systemctl restart sshCortafuegos y Fail2ban
En el servidor solo deben estar abiertos los puertos que realmente prestan servicio hacia el exterior. Unos buenos ajustes de firewall reducen la superficie de ataque; fail2ban, por su parte, bloquea automáticamente las direcciones que insisten en sus intentos.
5. Active el cortafuegos
En Ubuntu, UFW ofrece una interfaz sencilla sobre iptables. Permita primero SSH y active el cortafuegos después; si el orden es el inverso, perderá la conexión.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose6. Instale Fail2ban
Fail2ban vigila los registros y bloquea durante un tiempo determinado las direcciones IP que fallan repetidamente al iniciar sesión. Haga los ajustes no en el archivo principal, sino en jail.local, que las actualizaciones no sobrescriben.
sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban[sshd]
enabled = true
maxretry = 5
bantime = 1h
findtime = 10msudo systemctl restart fail2ban
sudo fail2ban-client status sshdActualizaciones y servicios
Buena parte de las brechas de seguridad proviene de software cuyo parche ya se publicó hace tiempo pero no se aplicó. Cada servicio innecesario en ejecución supone, además, un riesgo más.
7. Actualizaciones de seguridad automáticas
El paquete unattended-upgrades aplica los parches de seguridad sin que usted intervenga. Los saltos de versión mayor, en cambio, hágalos a mano de forma controlada, después de hacer una copia de seguridad.
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades8. Revise los puertos y servicios abiertos
Liste qué servicio escucha en qué puerto. Los servicios que solo deben ser accesibles desde dentro del servidor, como una base de datos, deben escuchar en 127.0.0.1 y no estar abiertos al exterior. Desactive los servicios que no utilice.
sudo ss -tulpn
sudo systemctl disable --now SERVIS_ADIMonitorización y copias de seguridad
Si publica un sitio web en el servidor, a estos pasos debe sumarse HTTPS; explicamos la instalación y la renovación automática del certificado gratuito en nuestro artículo sobre la instalación de un certificado SSL.
9. Supervise los registros y los recursos
La forma más fácil de detectar un ataque son los registros. Revise con regularidad los accesos SSH, la ocupación del disco y el uso anormal del procesador. Que la hora del servidor sea correcta también es imprescindible para que los registros tengan sentido.
sudo journalctl -u ssh --since today
df -h
timedatectl10. Planifique copias de seguridad e instantáneas
Ninguna medida de seguridad es infalible al cien por cien; la última línea de defensa es la copia de seguridad fuera del servidor. Utilice la función de instantáneas del proveedor, pero no confíe solo en ella: envíe también las copias de la base de datos y de los archivos a un almacenamiento aparte y pruebe la restauración con regularidad. Para la estrategia, consulte nuestra guía sobre cómo hacer copias de seguridad.
Si usa Docker, tenga cuidado
Los puertos publicados con Docker modifican directamente las reglas de iptables, por lo que pueden saltarse las reglas de UFW. Es decir, un puerto de base de datos que aparece cerrado en UFW puede ser accesible desde fuera si se publicó con docker run -p.
La solución es enlazar a 127.0.0.1 los puertos de contenedor que solo deben ser accesibles desde dentro del servidor y abrir hacia el exterior únicamente los puertos 80 y 443 a través de un proxy inverso (reverse proxy). Para más detalles, consulte la documentación oficial de redes de Docker.
docker run -d -p 127.0.0.1:5432:5432 postgresErrores habituales y próximos pasos
Estos diez pasos son solo un comienzo. La propia aplicación que se ejecuta en el servidor también debe mantenerse actualizada, los paneles de administración deben protegerse con verificación en dos pasos y, ante cualquier situación sospechosa, debe haber un plan de respuesta rápida. Explicamos paso a paso qué hacer tras un ataque en nuestro artículo sobre qué hacer si su sitio web ha sido hackeado.
Si no quiere llevar la administración del servidor con su propio equipo, nuestro servicio de velocidad y rendimiento, que aborda conjuntamente el alojamiento, la seguridad y la velocidad del sitio, asume esa carga. En nuestros proyectos de plataforma e-commerce, diseño web y soluciones de software sectoriales, la seguridad del servidor se planifica como parte del proceso de puesta en marcha.
| Error | Consecuencia | Cómo hacerlo bien |
|---|---|---|
| Activar UFW sin permitir SSH | Se pierde el acceso al servidor | Primero ufw allow OpenSSH |
| Desactivar el acceso con contraseña sin probar la clave | Se queda usted fuera | Pruebe en un segundo terminal |
| Dejar la base de datos abierta al exterior | Datos directamente expuestos a ataques | Enlácela a 127.0.0.1 |
| Guardar la copia de seguridad en el mismo servidor | La copia se pierde junto con el servidor | Utilice un almacenamiento aparte |
| Aplazar las actualizaciones durante meses | Las vulnerabilidades conocidas siguen abiertas | Actualizaciones de seguridad automáticas |
Preguntas frecuentes
01¿Cambiar el puerto SSH mejora la seguridad?
Cambiar el puerto 22 por defecto reduce el tráfico de bots automáticos y el ruido en los registros, pero no es una medida de seguridad real. La verdadera protección viene de medidas como el acceso con clave, el acceso con contraseña desactivado y fail2ban. Si cambia el puerto, no olvide permitir el nuevo puerto en el cortafuegos.
02¿Servidor gestionado o lo administro yo mismo?
Si domina la administración de Linux y puede dedicar tiempo al mantenimiento regular, puede gestionar el VPS usted mismo. Si no, un servicio gestionado o un equipo con experiencia garantiza que las tareas de actualización y monitorización no se descuiden; el mantenimiento que falla es la causa más frecuente de las brechas de seguridad.
03¿Qué hago si Fail2ban me bloquea a mí?
Puede entrar al servidor desde la consola web del proveedor y levantar el bloqueo con el comando sudo fail2ban-client set sshd unbanip DIRECCION_IP. Si tiene una IP fija, puede evitar que se repita añadiéndola a la línea ignoreip de jail.local.
En un VPS nuevo, estos diez ajustes neutralizan desde el primer día la inmensa mayoría de los ataques automáticos; junto con las actualizaciones periódicas y una copia de seguridad probada, forman una base sólida. Si quiere gestionar la seguridad y la velocidad de su servidor de forma conjunta y medible, conozca el servicio de velocidad y rendimiento de Aurora.
