Los errores al configurar un VPS pueden convertir un servidor potente en una puerta abierta para atacantes o en una fuente constante de caídas. La mayoría de los problemas graves que sufren los servidores VPS son prevenibles y se repiten una y otra vez entre usuarios que comienzan a administrar su propio servidor.
Esta guía recorre los diez errores más frecuentes, explica por qué son peligrosos y ofrece la corrección exacta para cada uno. Si estás configurando tu primer VPS o revisando uno ya en producción, aquí encontrarás la lista de verificación que necesitas.
1. Dejar el acceso root por SSH habilitado
El error más común y peligroso: dejar que el usuario root inicie sesión directamente por SSH. Los bots de fuerza bruta escanean internet continuamente intentando credenciales de root.
Corrección: Crea un usuario con privilegios sudo, deshabilita el login de root en /etc/ssh/sshd_config (PermitRootLogin no) y reinicia el servicio SSH.
adduser adminuser
usermod -aG sudo adminuser
# En /etc/ssh/sshd_config:
PermitRootLogin no2. No cambiar el puerto SSH predeterminado
El puerto 22 es el primero que escanean los atacantes. No cambiarlo no es un error crítico por sí solo, pero amplifica enormemente la superficie de ataque cuando se combina con contraseñas débiles.
Corrección: Cambia el puerto a un número alto (por ejemplo, 2299) en /etc/ssh/sshd_config. Recuerda abrir el nuevo puerto en el firewall antes de cerrar la sesión actual.
3. No configurar un firewall desde el primer momento
Un VPS recién instalado suele tener todos los puertos abiertos. Sin firewall, cualquier servicio que instales queda expuesto de inmediato a internet.
Corrección: Activa ufw o iptables justo después de la instalación del sistema operativo, antes de instalar cualquier otra cosa. Permite solo los puertos que necesites.
ufw allow 2299/tcp # tu puerto SSH personalizado
ufw allow 80/tcp
ufw allow 443/tcp
ufw enablePara un recorrido completo sobre reglas de firewall, consulta nuestra guía en la categoría de servidores VPS.
4. Usar contraseñas débiles o no usar llaves SSH
Las contraseñas cortas o predecibles son derrotadas por ataques de diccionario en minutos. Muchos proveedores envían la contraseña root por correo; cambiarla es obligatorio.
Corrección: Usa autenticación por llave pública SSH y deshabilita la autenticación por contraseña en el servidor.
# En /etc/ssh/sshd_config:
PasswordAuthentication no
PubkeyAuthentication yes5. No mantener el sistema actualizado
Las vulnerabilidades en el kernel y en los paquetes de sistema se publican constantemente. Un servidor sin actualizaciones acumula vectores de ataque conocidos.
Corrección: Aplica actualizaciones de seguridad regularmente. En distribuciones Debian/Ubuntu puedes automatizar las críticas:
apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgradesEn CentOS/AlmaLinux/Rocky usa dnf-automatic para el mismo efecto.
6. Olvidar configurar backups automáticos
Muchos administradores dan por sentado que el proveedor respalda el servidor. En un VPS no administrado, el backup es responsabilidad del cliente. Un solo fallo de disco o un ransomware sin backup puede costar días de trabajo.
Corrección: Configura backups automáticos desde el primer día. Puede ser un snapshot diario del proveedor, un script con rsync hacia almacenamiento externo, o ambos. Verifica que los backups se puedan restaurar.
| Método | Frecuencia recomendada | Costo típico |
|---|---|---|
| Snapshot del proveedor | Diario | ~$1–5 USD/mes extra |
| rsync a almacenamiento externo | Diario o por hora | Costo de almacenamiento |
| Backup de base de datos separado | Cada hora o menos | Casi gratis (local) |
7. No monitorear recursos ni logs
Sin monitoreo, un proceso desbocado puede consumir toda la RAM o el disco y tumbar el servidor horas antes de que el administrador lo note. Los logs son la primera pista cuando algo falla.
Corrección: Instala una herramienta mínima de monitoreo (Netdata, Prometheus + Grafana, o incluso alertas del proveedor). Revisa /var/log/syslog, /var/log/auth.log y los logs de aplicación regularmente.
8. No separar entornos (producción, staging, desarrollo)
Hacer cambios directamente en producción sin pruebas previas es una receta para caídas inesperadas. Un error en una actualización de código o de configuración puede tirar el sitio en segundos.
Corrección: Mantén al menos un entorno de staging, aunque sea en el mismo VPS con un virtualhost diferente. Prueba ahí antes de desplegar en producción.
9. Exponer servicios de base de datos a internet
MySQL, PostgreSQL y MongoDB no deberían escuchar en una interfaz pública. Cuando lo hacen, quedan expuestos a escaneos automáticos y ataques de inyección directa.
Corrección: Configura la base de datos para escuchar solo en 127.0.0.1 (localhost). Si necesitas acceso remoto, hazlo a través de un túnel SSH, nunca abriendo el puerto en el firewall.
# En /etc/mysql/mysql.conf.d/mysqld.cnf:
bind-address = 127.0.0.110. Ignorar los permisos de archivos y directorios
Permisos demasiado permisivos (777 en archivos web, por ejemplo) permiten a cualquier proceso del servidor leer o modificar archivos que no debería. Es un vector frecuente de escalada de privilegios.
Corrección: Los archivos web deben pertenecer al usuario del servidor web o al usuario de la aplicación, con permisos 644 para archivos y 755 para directorios. Nunca uses 777 en producción.
find /var/www/miapp -type f -exec chmod 644 {} \;
find /var/www/miapp -type d -exec chmod 755 {} \;Conclusiones clave
- Deshabilita el acceso root por SSH desde el primer momento y usa llaves públicas.
- Activa el firewall antes de instalar cualquier servicio.
- Configura backups automáticos y verifica que funcionen.
- Mantén el sistema actualizado con parches de seguridad.
- No expongas bases de datos ni servicios internos a internet.
- Monitorea recursos y revisa logs regularmente.
- Separa entornos: nunca despliegues directamente en producción sin probar.
- Aplica permisos de archivo correctos; nunca uses 777 en producción.
Si quieres asegurarte de no cometer ninguno de estos errores en tu próximo servidor, el equipo de elenlace.com puede acompañarte en la configuración y el hardening de tu VPS desde cero.
Preguntas frecuentes
¿Cuál es el error más grave al configurar un VPS?
Dejar el acceso root por SSH habilitado con autenticación por contraseña es, con diferencia, el error más peligroso. Los bots lo explotan de forma automatizada en cuestión de horas después de que el servidor sale a internet.
¿Con qué frecuencia debo hacer backups de mi VPS?
Como mínimo, una vez al día para datos críticos. Para bases de datos de comercio electrónico o aplicaciones transaccionales, considera backups por hora o incluso más frecuentes, con retención de al menos 7 días.
¿Necesito monitoreo si tengo un VPS pequeño?
Sí. Incluso un VPS de 1 GB de RAM puede saturarse con un proceso mal configurado o un ataque DDoS menor. El monitoreo básico es gratuito (Netdata Community) y puede alertarte antes de que el problema afecte a tus usuarios.
¿Es obligatorio cambiar el puerto SSH?
No es obligatorio, pero reduce drásticamente el ruido de los bots en los logs y la superficie de ataque automático. Lo más importante es deshabilitar la autenticación por contraseña y el login de root; el cambio de puerto es una capa adicional de defensa en profundidad.
¿Prefieres que lo hagamos por ti? En El Enlace resolvemos hosting y desarrollo web profesional.
Para saber más
Otros proveedores y guías que vale la pena comparar:
