Guía de Seguridad en VPS y Docker: Hardening para DevOps

Introducción: El nuevo paradigma de la seguridad en el borde

La proliferación de servicios expuestos a internet mediante contenedores ha convertido a los VPS mal configurados en el blanco predilecto de bots y actores malintencionados. En el ecosistema actual, donde la velocidad de despliegue suele sacrificar la integridad del sistema, entender la seguridad en VPS y Docker no es opcional: es la base sobre la cual se construye cualquier producto tecnológico escalable.

Como arquitectos y desarrolladores, nuestra responsabilidad trasciende la escritura de código limpio; debemos garantizar que el entorno de ejecución sea una fortaleza. En esta guía, desglosaremos las capas de defensa necesarias para proteger tu infraestructura desde el kernel de Linux hasta la orquestación de contenedores.

1. El bastionado del sistema operativo (OS Hardening)

Antes de siquiera considerar la instalación de Docker, tu servidor debe estar blindado. Un VPS expuesto con credenciales débiles será comprometido en cuestión de minutos.

Deshabilitar acceso root y SSH seguro

El primer paso es eliminar la puerta de entrada principal. El usuario root nunca debe tener acceso SSH directo.

1. Crea un usuario con privilegios: adduser nombre_usuario y asígnale permisos de sudo.
2. Edita /etc/ssh/sshd_config:
   • PermitRootLogin no
   • PasswordAuthentication no (Utiliza únicamente autenticación mediante claves ed25519).

Implementación de Fail2Ban

Fail2Ban es la red de seguridad automática que escanea tus logs en busca de patrones de autenticación fallidos y bloquea las IPs infractoras mediante iptables o nftables.

2. Docker: Arquitectura de seguridad desde el despliegue

Docker por defecto no es inseguro, pero su configuración estándar está diseñada para la facilidad de desarrollo, no para la producción.

El peligro del socket de Docker

El error más crítico en la seguridad en VPS y Docker es exponer /var/run/docker.sock. Si un atacante compromete un contenedor que tiene acceso a este socket, obtiene acceso root total al host.

Tabla Comparativa: Configuraciones de Riesgo vs. Seguridad

Característica	Configuración Insegura	Configuración Recomendada (Hardened)
Usuario del Contenedor	Root (Default)	Usuario no privilegiado (UID > 1000)
Acceso al Host	/var/run/docker.sock montado	Uso de Docker Proxy o API restringida
Redes	Modo host o bridge compartido	Redes privadas definidas (docker network)
Privilegios	--privileged activo	--cap-drop=ALL con cap-add específico
Imágenes	latest (tags no fijos)	Tags inmutables (SHA256 digest)

3. Implementación de buenas prácticas en Dockerfile

Para mitigar vectores de ataque, tus imágenes deben ser minimalistas y seguras.

# Ejemplo de Dockerfile seguro (Hardened)
FROM node:20-alpine AS build

# No ejecutar como root
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app

# Copiar dependencias y buildear
COPY package*.json ./
RUN npm ci --only=production

# Cambiar a usuario sin privilegios
USER appuser

# Exponer solo el puerto necesario
EXPOSE 3000

# Usar ENTRYPOINT para evitar ejecución de shells innecesarios
ENTRYPOINT ["node", "dist/server.js"]

4. Gestión de Redes y Firewalling

Linux es excelente gestionando la seguridad a nivel de red, pero Docker tiende a “saltarse” las reglas de iptables al crear sus propios puentes.

Uso de UFW y Docker

Para que tus reglas de UFW (Uncomplicated Firewall) sean efectivas, debes configurar Docker para que respete el firewall. Modifica /etc/docker/daemon.json:

{
  "iptables": true,
  "live-restore": true,
  "userland-proxy": false,
  "no-new-privileges": true
}

5. Errores comunes que comprometen tu infraestructura

Incluso los ingenieros más experimentados cometen fallos por omisión. Aquí los errores que debes evitar a toda costa:

1. Hardcoding de secretos: Jamás incluyas archivos .env en tu control de versiones. Utiliza herramientas de gestión de secretos como Docker Secrets o servicios de terceros como HashiCorp Vault.
2. Imágenes desde registros públicos sin validación: Descargar imágenes desde Docker Hub sin verificar la firma o el origen es invitar a un ataque de supply chain.
3. No actualizar el Host ni el Engine: Las vulnerabilidades de “cero día” en el kernel de Linux o en la versión de Docker son parches constantes. Automatiza el ciclo de vida de actualización (ej. unattended-upgrades en Debian/Ubuntu).
4. Logs excesivos: A veces, los logs contienen información sensible (tokens, headers de autorización). Configura un recolector de logs que filtre información crítica antes de enviarla a tu stack de observabilidad.

6. Monitoreo: La visibilidad es seguridad

Si no puedes ver qué está pasando en tu infraestructura, no puedes protegerla. Implementar un stack de seguridad básica requiere:

• Auditd: Para monitorear llamadas al sistema (syscalls) sospechosas.
• Prometheus + Grafana: Para detectar comportamientos anómalos en el uso de CPU/RAM de los contenedores, lo cual suele ser señal de un minero de criptomonedas instalado ilegalmente.
• Trivy: Integra esta herramienta en tu pipeline CI/CD para escanear vulnerabilidades en cada imagen antes de que llegue a producción.

Conclusión: Hacia una arquitectura resiliente

La seguridad en VPS y Docker no es un destino, sino un proceso iterativo de mejora continua. Al aplicar estas capas de protección, no solo estás protegiendo tus datos, sino que estás construyendo una reputación de confiabilidad, un activo invaluable para cualquier desarrollador full stack.

La infraestructura cloud exige una mentalidad de “defensa en profundidad”. Si quieres llevar tus despliegues al siguiente nivel y asegurar que tu infraestructura soporte la carga de trabajo de mañana, te invito a explorar mis proyectos de infraestructura y servicios de consultoría en izerick.dev. Mantener el control de tus servidores es el primer paso para dominar el despliegue moderno. ¡A asegurar el entorno!