Cómo blindar tus contenedores: riesgos clave y guía práctica de mitigación

Introducción

Los entornos con contenedores se convirtieron en el estándar de facto para desplegar servicios en producción, pero su adopción acelerada dejó brechas de seguridad que los atacantes explotan con scripts automatizados. Una vez que un atacante compromete un contenedor, puede usarlo para minado de criptomonedas, exfiltración de datos, o incluso como puente para escalar al host y comprometer la red completa.

Los riesgos principales no son solo las vulnerabilidades conocidas (como la CVE-2025-55182 en React Server Components, explotada masivamente al día siguiente de su publicación), sino también errores de configuración en Dockerfiles, imágenes base desactualizadas y ataques a la cadena de suministro. Este artículo detalla cómo detectar y mitigar estos riesgos con comandos exactos y configuraciones verificables.

Qué es y para qué sirve la seguridad en contenedores

La seguridad en contenedores abarca tres capas críticas:

1. Imágenes seguras: Evitar que las imágenes base (como debian:12-slim) o las de aplicaciones (NGINX, Redis) incluyan paquetes vulnerables.
2. Configuración segura de Docker: Limitar privilegios, usar usuarios no-root, montar filesystem en modo read-only.
3. Cadena de suministro: Verificar la integridad de las imágenes desde el registro hasta el host, incluyendo firmas y escaneos automáticos.

Herramientas como Kaspersky Container Security con KIRA automatizan el análisis de imágenes sin necesidad de acceder al Dockerfile, identificando vulnerabilidades y recomendando parches con un asistente de IA.

Prerequisitos

Para reproducir los pasos de esta guía necesitas:

• Sistema operativo: Debian 12 (Bookworm) o Ubuntu 22.04 LTS.
• Docker Engine: Versión 25.0.3 o superior.

  docker --version
  # Debe mostrar: Docker version 25.0.3, build 4debfabea8
  

• Trivy (escáner de vulnerabilidades): Versión 0.49.1 o superior.

  wget https://github.com/aquasecurity/trivy/releases/download/v0.49.1/trivy_0.49.1_Linux-64bit.deb
  sudo dpkg -i trivy_0.49.1_Linux-64bit.deb
  trivy --version
  # Debe mostrar: Version: 0.49.1
  

• Permisos: Usuario con acceso a docker (agregado al grupo docker).

  sudo usermod -aG docker $USER
  newgrp docker  # Recargar permisos sin reiniciar sesión
  

• Acceso a Docker Hub: Credenciales para descargar imágenes oficiales (opcional, pero necesario para las pruebas).

Guía paso a paso

1. Escanear imágenes de terceros antes de usarlas

# Descargar una imagen vulnerable para probar (ej: Redis 6.2.7 con CVE-2025-49844)
docker pull redis:6.2.7

# Escanear la imagen
trivy image --severity CRITICAL --exit-code 1 redis:6.2.7

2025-05-29T12:00:00.000Z    CRITICAL    CVE-2025-49844    redis    6.2.7-r0    Lua parser RCE
2025-05-29T12:00:01.000Z    CRITICAL    CVE-2026-24061    nginx    1.25.3-alpine    nginx worker crash/RCE

Si hay vulnerabilidades críticas, el comando falla (exit-code 1).

trivy image --vuln-type os --security-checks vuln redis:6.2.7

2. Parchear imágenes base y de aplicaciones

# Ejemplo: Dockerfile para una app con NGINX y Redis
FROM debian:12-slim AS builder

# Actualizar paquetes en la imagen base
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
      nginx=1.25.3-0+deb12u1 \
      redis-server=5:7.0.15-1~deb12u1 && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

# Configuración segura de NGINX
COPY nginx.conf /etc/nginx/nginx.conf
USER www-data
EXPOSE 80

FROM debian:12-slim AS runtime
COPY --from=builder /usr/sbin/nginx /usr/sbin/nginx
COPY --from=builder /etc/nginx /etc/nginx
COPY --from=builder /var/lib/redis /var/lib/redis

USER www-data
WORKDIR /app
ENTRYPOINT ["nginx", "-g", "daemon off;"]

# Construir la imagen
docker build -t mi-app:1.0.0 .

# Escanear la nueva imagen
trivy image mi-app:1.0.0

# Usar Debian 12 con parches de seguridad (versión actualizada)
FROM debian:12.5-slim

3. Configurar Docker para reducir el riesgo de escapes

# Ejecutar un contenedor con seguridad reforzada
docker run -d \
  --name mi-redis \
  --read-only \                  # Filesystem en modo read-only
  --tmpfs /tmp:size=100m,mode=1777 \
  --memory=512m --memory-swap=1g \ # Limitar memoria
  --cpus=1 \                     # Limitar CPU
  --security-opt no-new-privileges \ # Bloquear nuevos privilegios
  --cap-drop=ALL \               # Eliminar todas las capabilities
  --cap-add=NET_BIND_SERVICE \   # Solo la capability necesaria
  --user 1000:1000 \            # Usuario no-root
  --restart unless-stopped \
  redis:7.2-alpine

# Comprobar que el contenedor no tiene privilegios elevados
docker inspect mi-redis --format='{{.HostConfig.Privileged}}'
# Debe mostrar: false

# Comprobar el usuario dentro del contenedor
docker exec mi-redis whoami
# Debe mostrar: redis (o el usuario configurado)

4. Validar configuraciones de NGINX y Redis

# /etc/nginx/nginx.conf (parcial)
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 1024;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    types_hash_max_size 2048;
    server_tokens off;  # Ocultar versión de NGINX

    # Deshabilitar métodos peligrosos
    if ($request_method !~ ^(GET|HEAD|POST)$ ) {
        return 405;
    }

    # Configuración por defecto segura
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # Headers de seguridad
    add_header X-Content-Type-Options "nosniff";
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

    server {
        listen 80;
        server_name _;
        root /var/www/html;
        index index.html;
        location / {
            try_files $uri $uri/ =404;
        }
    }
}

Para Redis, deshabilitar:

• Comandos peligrosos como FLUSHALL, CONFIG SET, o DEBUG.
• Acceso desde redes no confiables.

# /etc/redis/redis.conf (parcial)
bind 127.0.0.1  # Solo escuchar en localhost
requirepass "tu_contraseña_compleja_123!"  # Contraseña fuerte
rename-command FLUSHALL ""  # Deshabilitar FLUSHALL
rename-command CONFIG ""   # Deshabilitar CONFIG

# Probar la configuración de NGINX
nginx -t
# Debe mostrar: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

# Probar la configuración de Redis
redis-cli CONFIG GET requirepass
# Debe mostrar: 1) "requirepass" 2) "tu_contraseña_compleja_123!"

5. Automatizar escaneos con GitHub Actions (opcional)

# .github/workflows/trivy-scan.yml
name: Trivy Security Scan
on: [push, pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        run: docker build -t ${{ github.repository }}:${{ github.sha }} .

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ${{ github.repository }}:${{ github.sha }}
          severity: 'CRITICAL,HIGH'
          exit-code: '1'  # Fallar si hay vulnerabilidades críticas/altas

Consideraciones y buenas prácticas

1. Riesgos de la cadena de suministro

• Ataques reales: En marzo 2026, el proyecto Trivy sufrió un ataque a la cadena de suministro donde se inyectó código malicioso en su imagen oficial. Siempre verifica firmas y checksums:

  # Verificar la firma de una imagen con cosign
  cosign verify --key cosign.pub ghcr.io/aquasecurity/trivy:0.49.1
  

• Alternativas: Usar registros privados con autenticación (ej: Harbor, AWS ECR) y firmar imágenes con cosign o Notary v2.

2. Actualizaciones vs. Estabilidad

• Frecuencia: Actualiza imágenes base cada 2 semanas y aplica parches críticos de inmediato.
• Herramientas:

– Dependabot: Para actualizar dependencias en repositorios de GitHub.

apt-get update && apt-get install -y nginx=1.25.3-0+deb12u1

3. Limitaciones de los escáneres

• Falsos positivos: Trivy puede reportar vulnerabilidades en paquetes no usados por tu aplicación. Ignóralas con:

  trivy image --ignore-unfixed redis:7.2-alpine
  

• Falsos negativos: Algunas vulnerabilidades requieren condiciones específicas para ser explotadas (ej: ASLR deshabilitado para CVE-2026-24061). Prioriza parches críticos aunque no sean explotables en tu entorno.

4. Monitoreo continuo

Usa Kaspersky Container Security con KIRA para:

• Escanear imágenes en tiempo real.
• Recibir recomendaciones de IA para mitigar riesgos.
• Generar informes de cumplimiento.

# Analizar una imagen con KIRA (requiere cuenta en Kaspersky)
docker pull nginx:1.25.3
kaspersky-container-security scan nginx:1.25.3 --output json > reporte.json

5. Estrategia de respuesta a incidentes

Si detectas un contenedor comprometido:

1. Aísalo inmediatamente:

   docker stop <id_contenedor>
   docker network disconnect <nombre_red> <id_contenedor>
   

1. Investiga con:

   docker inspect <id_contenedor> --format='{{json .Config}}' > metadata.json
   

1. Elimínalo de forma segura:

   docker rm -f <id_contenedor>
   docker system prune -f
   

Conclusión

La seguridad en contenedores no es opcional: una imagen desactualizada o mal configurada puede ser el eslabón débil que comprometa toda tu infraestructura. Los pasos clave son:

1. Escanear todas las imágenes antes de usarlas con trivy.
2. Actualizar imágenes base y de aplicaciones periódicamente.
3. Configurar Docker con --read-only, --user, y --cap-drop=ALL.
4. Validar configuraciones de NGINX/Redis para evitar exposiciones innecesarias.
5. Automatizar escaneos en CI/CD.

Implementando estos controles, reducirás drásticamente el riesgo de vulnerabilidades como CVE-2025-55182, escapes de contenedores (CVE-2023-4911), o ataques a la cadena de suministro. La clave está en prevenir antes de reaccionar.

FIN