Cómo configurar y asegurar un VPS Linux desde cero para proyectos web

Levantar un VPS es fácil. Levantarlo bien —de forma estable, rápida y resistente a los escaneos automáticos que golpean cualquier IP pública desde el minuto uno— es otra historia. Esta guía recorre el camino completo: desde el primer ssh root@ hasta tener un servidor listo para alojar un proyecto web en producción, con las capas de seguridad que un VPS necesita para no convertirse en un problema.

1. Elegir el VPS y el sistema operativo

Para la mayoría de proyectos web (WordPress, una API en Node, una app en Django o un sitio estático servido con Nginx), 1-2 vCPU y 2 GB de RAM son un punto de partida razonable. Distribuciones recomendadas:

Ubuntu Server LTS (22.04 o 24.04): la más documentada, ideal si es tu primer VPS.
Debian 12: más ligera y conservadora en actualizaciones.
AlmaLinux/Rocky Linux: si el stack requiere compatibilidad con RHEL.

Esta guía usa comandos de Ubuntu/Debian (apt), pero los conceptos aplican a cualquier distribución.

Comprar un Hosting VPS con Descuento!

2. Primer acceso y actualización del sistema

Conectate por SSH con las credenciales que te dio el proveedor:

ssh root@TU_IP_PUBLICA

Lo primero, siempre, es actualizar los paquetes del sistema:

apt update && apt upgrade -y

Esto cierra vulnerabilidades conocidas antes de instalar nada más.

3. Crear un usuario sin privilegios de root

Trabajar como root de forma permanente es un riesgo innecesario. Creá un usuario con permisos de sudo:

adduser deploy
usermod -aG sudo deploy

De acá en adelante, todo el trabajo diario se hace con este usuario, usando sudo solo cuando haga falta.

4. Autenticación por clave SSH (y por qué desactivar las contraseñas)

Las contraseñas son el vector de ataque por fuerza bruta más común contra un VPS. La alternativa es autenticación por par de claves.

En tu máquina local, si todavía no tenés una clave:

ssh-keygen -t ed25519 -C "tu_email@ejemplo.com"
ssh-copy-id deploy@TU_IP_PUBLICA

En el servidor, editá la configuración de SSH:

sudo nano /etc/ssh/sshd_config

Ajustá estos valores:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Port 2222

Cambiar el puerto por defecto (22) no es seguridad real —cualquier escáner lo encuentra igual— pero reduce drásticamente el ruido de bots automatizados en los logs. Reiniciá el servicio:

sudo systemctl restart ssh

Importante: antes de cerrar la sesión actual, abrí una segunda terminal y verificá que podés entrar con el nuevo usuario, clave y puerto. Si algo falla y cerrás la única sesión activa, podés quedar fuera del servidor.

5. Firewall: solo lo necesario, expuesto

ufw (Uncomplicated Firewall) es la forma más simple de gestionar iptables en Debian/Ubuntu:

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp      # tu puerto SSH
sudo ufw allow 80/tcp        # HTTP
sudo ufw allow 443/tcp       # HTTPS
sudo ufw enable

Regla de oro: denegar todo por defecto y abrir solo lo que el proyecto necesita. Cada puerto abierto es superficie de ataque.

6. Fail2ban: bloqueo automático de intentos de intrusión

Fail2ban monitorea los logs y banea IPs que fallan repetidamente al autenticarse:

sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

En /etc/fail2ban/jail.local, activá la jail de SSH y ajustá el puerto si lo cambiaste:

[sshd]
enabled = true
port = 2222
maxretry = 4
bantime = 1h

sudo systemctl restart fail2ban

7. Actualizaciones de seguridad automáticas

Para no depender de acordarte de actualizar manualmente:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Esto aplica parches de seguridad críticos sin intervención manual, reduciendo la ventana de exposición ante vulnerabilidades recién publicadas.

8. Configurar memoria swap

En VPS con poca RAM, un swap evita que procesos se caigan por falta de memoria bajo picos de carga:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

9. Instalar el stack web

Para un sitio o API servido con Nginx como proxy inverso:

sudo apt install nginx -y
sudo systemctl enable nginx

Configurá un bloque de servidor en /etc/nginx/sites-available/tu-proyecto, apuntando al puerto de tu aplicación (Node, Gunicorn, PHP-FPM, etc.), y habilitalo:

sudo ln -s /etc/nginx/sites-available/tu-proyecto /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Certificado SSL gratuito con Let’s Encrypt

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d tudominio.com -d www.tudominio.com

Certbot configura la renovación automática por defecto; podés verificarla con:

sudo certbot renew --dry-run

10. Backups: la capa que nadie prioriza hasta que la necesita

Como mínimo, automatizá backups periódicos de la base de datos y de los archivos del proyecto, y almacenalos fuera del VPS (otro proveedor, S3, o similar). Un backup que vive en el mismo disco que puede fallar no es un backup real. Herramientas simples como rsync, restic o borgbackup combinadas con un cron job cubren la mayoría de los casos.

11. Monitoreo básico

Para tener visibilidad sin montar infraestructura compleja:

htop para uso de CPU/RAM en tiempo real.
df -h para espacio en disco.
journalctl -xe para revisar logs del sistema.
Un servicio externo de uptime monitoring (gratuito en la mayoría de los casos) que te avise si el servidor deja de responder.

Checklist final antes de pasar a producción

Sistema actualizado (apt upgrade)
Usuario sin privilegios de root creado y probado
Login por contraseña deshabilitado, solo claves SSH
Puerto SSH cambiado y verificado con una segunda sesión activa
Firewall activo, solo puertos necesarios abiertos
Fail2ban corriendo sobre el servicio SSH
Actualizaciones de seguridad automáticas configuradas
Swap configurado si la RAM es limitada
Nginx (u otro proxy) sirviendo el proyecto
Certificado SSL activo y con renovación automática
Backups automáticos y almacenados fuera del servidor
Monitoreo básico de recursos y disponibilidad

Conclusión

Asegurar un VPS no es un paso único sino una serie de capas que se refuerzan entre sí: acceso restringido, superficie de ataque mínima, detección de intentos de intrusión y un plan de recuperación si algo falla. Ninguna de estas medidas es complicada por separado; la seguridad real está en aplicarlas todas, de forma consistente, antes de poner el proyecto en manos de usuarios reales.