Checklist de seguridad para VPS Linux antes de poner servicios en producción: hardening, SSH, backups y monitorización

Por Kevin Marcondes · Publicado el 02/10/2026 · Actualizado el 12/10/2026 · 10 min de lectura

Antes del go‑live, usa este checklist de seguridad para VPS Linux antes de poner servicios en producción (hardening, SSH, backups, monitorización). Ofrece pasos prácticos para reducir la superficie de ataque, proteger accesos, activar TLS, configurar firewall y alertas, y validar backups. Aplícalo como lista de verificación para llegar a producción con menos riesgos y una recuperación más rápida.

Cómo usar este checklist de forma práctica

Trata cada sección como una etapa obligatoria antes del go‑live. Marca lo completado y registra evidencias: comandos ejecutados, archivos modificados y capturas de pantalla de los paneles de monitorización.

Aplica en tres momentos: en la preparación inicial del VPS, antes de cada release relevante y tras incidentes. Reevalúa permisos, puertos abiertos y políticas de actualización con regularidad.

Integra al control de cambios: versionado de archivos de configuración, PRs revisados y aprobaciones. Guarda las evidencias en un repositorio interno para auditoría.

Si tu equipo usa runbooks, integra este checklist. Es complementario a las políticas de seguridad y no las reemplaza.

• Define un responsable para cada etapa.
• Registra fecha y resultado de la verificación.
• Automatiza cuando sea posible (scripts e IaC).

Cuentas, privilegios y acceso seguro

Separa cuentas administrativas de las de aplicación. Deshabilita el login directo del root y usa sudo solo cuando sea necesario. La autenticación debe ser por claves SSH, nunca por contraseña en producción.

Restringe quién puede acceder vía SSH y considera segundo factor (TOTP/U2F) y/o un bastión para acceso mediado. Consulta la guía del bastión con 2FA en Bastión SSH con claves y 2FA.

Mantén las claves rotadas y elimina accesos de ex‑colaboradores. Para servicios, prefiere tokens de corta duración y secretos fuera del código.

• Cuenta administrativa dedicada (ej.: deploy).
• Root sin login remoto.
• Sudo con registro (sudo -l y logs).
• Claves SSH fuertes y rotadas.
• Acceso por IPs conocidas o VPN.

# criar usuário administrativo e configurar SSH por chave
adduser deploy
usermod -aG sudo deploy
mkdir -p ~deploy/.ssh && chmod 700 ~deploy/.ssh
# cole sua chave pública no arquivo abaixo
nano ~deploy/.ssh/authorized_keys
chmod 600 ~deploy/.ssh/authorized_keys
chown -R deploy:deploy ~deploy/.ssh

# desabilitar login root por SSH e reiniciar serviço
sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl reload sshd || service ssh restart

Sistema actualizado y servicios mínimos

Mantén el sistema actualizado y activa actualizaciones de seguridad automáticas. Tras upgrades de kernel, programa ventanas de reboot. Elimina paquetes y servicios innecesarios para reducir la superficie de ataque.

Revisa servicios habilitados en el arranque y desactiva lo que no necesites. Realiza escaneos puntuales para detectar paquetes expuestos desactualizados.

Considera eliminar herramientas de compilación en hosts de producción, desinstalar servidores no usados y bloquear módulos de kernel innecesarios cuando proceda.

• Actualizaciones aplicadas y pendientes resueltas.
• Actualizaciones de seguridad automáticas activas.
• Servicios innecesarios eliminados.
• Reboot planificado tras actualización de kernel.

# atualizar sistema e configurar atualizações automáticas (Debian/Ubuntu)
apt update && apt full-upgrade -y
apt install -y unattended-upgrades
# assistente para ativar atualizações automáticas
DPKG_FRONTEND=noninteractive dpkg-reconfigure --priority=low unattended-upgrades

# listar serviços habilitados para revisar
systemctl list-unit-files --type=service --state=enabled

Firewall y endurecimiento de red

Aplica una política por defecto de deny (entradas) y allow (salidas), abriendo solo los puertos necesarios. Limita intentos de conexión al SSH. Endurece parámetros de red con sysctl para mitigar escaneos y spoofing.

Para IPv6, asegura reglas equivalentes a las de IPv4. Realiza un escaneo externo (nmap) desde otra máquina para confirmar que solo está expuesto lo estrictamente necesario.

Para un paso a paso con UFW, consulta la guía de firewall en Ubuntu con UFW.

• Política por defecto: deny incoming, allow outgoing.
• Puertos mínimos abiertos (80/443 y 22 cuando sea necesario).
• Rate‑limit en SSH (UFW limit).
• sysctl con protección contra IP spoofing y SYN cookies.
• Reglas consistentes para IPv6 (si está activo).

# política de firewall com UFW
ufw default deny incoming
ufw default allow outgoing
ufw allow 80,443/tcp
ufw allow 22/tcp && ufw limit 22/tcp
ufw enable
ufw status verbose

SSH endurecido y, si es posible, con bastión

Fortalece el sshd_config para solo claves, número reducido de intentos y keepalive corto. Evita cambiar la puerta 22 como única defensa; prioriza autenticación fuerte y restricción por IP/VPN.

Para accesos de equipos y terceros, centraliza en un bastión con registro y 2FA. Consulta el paso a paso en Bastión SSH con claves y 2FA.

Usa fail2ban para bloquear intentos maliciosos y define AllowUsers/AllowGroups explícitamente. Revisa periódicamente los logs de auth en busca de señales de brute force.

• Solo claves (sin contraseña).
• PermitRootLogin no.
• MaxAuthTries bajo (ej.: 3).
• AllowUsers con lista explícita.
• Keepalive para desconectar sesiones inactivas.

# /etc/ssh/sshd_config (trecho recomendado)
Port 22
Protocol 2
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
# restrinja usuários autorizados
AllowUsers deploy
UsePAM yes
# ative ChallengeResponseAuthentication apenas se usar 2FA via PAM
# ChallengeResponseAuthentication yes

TLS, HTTPS y seguridad en las aplicaciones

Usa HTTPS en todo el tráfico público. Automatiza emisión y renovación de certificados con ACME, y aplica políticas como HSTS y redirección 80→443. Configura proxies reversos con cabeceras de seguridad mínimas.

Evalúa protocolos y cifrados soportados, eliminando versiones obsoletas. Habilita stapling de OCSP y ALPN cuando sea aplicable. En HSTS, ten cuidado con subdominios si todavía hay servicios sin TLS.

Si necesitas una guía práctica, consulta cómo generar certificados en SSL gratis con Let's Encrypt.

• Certificados válidos y renovación automática.
• Redirección de HTTP a HTTPS.
• HSTS habilitado cuando proceda.
• TLS moderno sin protocolos obsoletos.

# emitir certificado usando o modo standalone (pare o serviço HTTP temporariamente)
apt update && apt install -y certbot
certbot certonly --standalone \
  -d example.com -d www.example.com \
  --agree-tos -m [email protected] --no-eff-email
# teste de renovação
certbot renew --dry-run

Monitorización, logs y alertas accionables

Recopila métricas del sistema (CPU, memoria, disco, red), disponibilidad y errores de aplicaciones. Configura alertas con umbrales claros y responsables. Retén logs con rotación y centralización cuando sea posible.

Añade comprobaciones de uptime desde fuera del VPS. Alertas de pre‑vencimiento de certificados, fallos de backup y uso de disco previenen incidentes. Documenta quién atiende alertas y el playbook de respuesta.

Para visualizar métricas, combina Prometheus y Grafana. Hay una guía con Docker Compose en configurar Prometheus y Grafana.

• Métricas del host (Node Exporter).
• Dashboards de servicios críticos.
• Alertas para disco lleno, OOM y picos de latencia.
• Logs con rotación y retención definida.
• fail2ban para banear IPs maliciosas.

# instalar métricas básicas do host (Debian/Ubuntu)
apt update && apt install -y prometheus-node-exporter
systemctl enable --now prometheus-node-exporter
# restrinja a porta 9100 ao IP do Prometheus (exemplo)
ufw allow from 203.0.113.10 to any port 9100 proto tcp

Backups verificados y plan de recuperación

Define qué se va a salvar: bases de datos, archivos de aplicación, configuraciones y secretos. Realiza backups automáticos fuera del VPS, con retención y cifrado. Lo crítico es probar la restauración: simula la recuperación periódicamente.

Integra comprobaciones de integridad, alertas de fallo y control de espacio en disco. Documenta quién activa el plan y en cuánto tiempo cada servicio debe volver. Ten cuidado al almacenar claves y contraseñas en scripts.

Establece RPO/RTO realistas, valida restores en entorno aislado y guarda passphrases fuera del VPS. Si usas snapshots del proveedor, combínalos con dumps consistentes de las bases.

• Backups automáticos off‑site y cifrados.
• Pruebas de restauración regulares.
• Retención por capas (diario/semanal/mensual).
• Documentación del plan de recuperación.
• Acceso restringido a las claves de backup.

#!/usr/bin/env bash
# backup básico (exemplo). Ajuste caminhos e credenciais.
set -euo pipefail
TS=$(date +%F-%H%M)
HOST=$(hostname -s)
BACKUP_DIR=/var/backups
REMOTE="[email protected]:/backups/${HOST}/"

mkdir -p "$BACKUP_DIR/db" "$BACKUP_DIR/files"

# dumps (ajuste usuários y senhas via .pgpass/.my.cnf ou variáveis seguras)
pg_dumpall | gzip > "$BACKUP_DIR/db/postgres-$TS.sql.gz" || true
mysqldump --all-databases --single-transaction | gzip > "$BACKUP_DIR/db/mysql-$TS.sql.gz" || true

# archivos críticos
tar czf "$BACKUP_DIR/files/etc-$TS.tgz" /etc
tar czf "$BACKUP_DIR/files/app-$TS.tgz" /var/www || true

# sincronizar para almacenamiento externo
rsync -az --delete "$BACKUP_DIR/" "$REMOTE"

# retención local de 7 días
find "$BACKUP_DIR" -type f -mtime +7 -delete

echo "Backup concluído em $TS"

Preguntas frecuentes

¿Con qué frecuencia debo ejecutar este checklist en el VPS?

Úsalo en la preparación inicial, antes de cada release relevante y tras cualquier incidente. Para mantenimiento, revisa mensualmente puntos críticos como actualizaciones, puertos abiertos, fallos de login, uso de disco, estado de backups y alertas. Ajusta la cadencia según la criticidad del servicio.

¿Cambiar el puerto 22 aumenta la seguridad del SSH?

Cambiar la puerta reduce el ruido de scans automatizados, pero no sustituye medidas esenciales: autenticación por clave, deshabilitar contraseñas y root, limitar intentos y, idealmente, restringir por IP o VPN. Usa el cambio de puerto solo como complemento.

¿UFW es suficiente o debo usar iptables directamente?

Para la mayoría de escenarios UFW es suficiente y menos propenso a errores. UFW genera reglas iptables por debajo. Si necesitas reglas avanzadas, múltiples tablas o marcajes, puedes configurar iptables o nftables directamente, manteniendo documentación y pruebas de regresión.

¿Cómo validar que los backups realmente funcionan?

Realiza restauraciones de prueba en entorno aislado. Verifica integridad de archivos, consistencia de bases y que el sistema vuelve a operar. Documenta el tiempo de recuperación y pasos. Automatiza comprobaciones de éxito de los jobs y alerta en fallos o tiempos superiores a lo esperado.

¿Qué métricas debo monitorizar en una VPS de producción?

Monitoriza CPU, memoria, disco (uso e IO), latencia de red, conexiones, errores de aplicación, tiempos de respuesta, colas y tasas de error por endpoint. Añade alertas para disco lleno, OOM, caídas de servicio, certificados próximos a vencer y fallos en jobs de backup.

Ver también

• Guía: checklist de pre‑deploy y plan de rollback rápido para aplicaciones PHP en producción
• Checklist de seguridad para pipelines CI/CD con runners self‑hosted y gestión de secretos
• Guía: centralización de logs con Fluentd y Elasticsearch para aplicaciones PHP en VPS
• Guía: organizar migraciones y rollbacks en PostgreSQL para equipos pequeños