InfraFenceInfraFence

Live Security Operations

Empezar

Seguridad de hosts Docker

Última actualización:

Es fácil dejar abierto un host Docker sin querer. Un puerto publicado por un contenedor no pasa por tus reglas de INPUT, así que ufw o firewalld pueden dar un puerto por cerrado mientras internet sigue llegando al contenedor que hay detrás. Y el tráfico web de tus sitios suele estar en la salida de los contenedores, no en un archivo de log del host.

Esta página explica qué hace Docker con el firewall y cómo el agente de InfraFence protege el host y sus contenedores. Los datos sobre Docker vienen de su documentación oficial, a noviembre de 2026.

Los puertos publicados se saltan tus reglas de INPUT

El tráfico hacia un puerto publicado de un contenedor se reenvía al contenedor, no se entrega al host, así que pasa por la ruta FORWARD. La documentación de Docker lo dice sin rodeos para ufw: los paquetes se enrutan antes de que se apliquen las reglas del firewall. Docker deja una cadena para tus propias reglas, DOCKER-USER, que evalúa antes que las suyas.

Por eso, un firewall que solo escribe reglas en INPUT protege los servicios del propio host, no los contenedores. Un contenedor de base de datos arrancado con -p 3306:3306 queda abierto al mundo aunque ufw deniegue el 3306.

Cómo gestiona el agente el firewall de Docker

  • Los bloqueos llegan a los contenedores. Cuando hay Docker, el agente salta a su propia cadena INFRAFENCE desde DOCKER-USER además de desde INPUT, y mantiene ese salto en primer lugar. Así, los bloqueos, las listas de amenazas y los bloqueos por país también se aplican a los puertos publicados por los contenedores. Si un reinicio de Docker o una recarga del firewall elimina el salto, el agente lo vuelve a poner.
  • Los puertos de bases de datos expuestos se pueden cerrar, también los de contenedores. Un puerto de base de datos, caché o administración abierto a internet (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch, la API de Docker y los demás que conoce el agente) se puede cerrar desde el panel de InfraFence. La regla compara el puerto que pidió el cliente (--ctorigdstport), que sigue siendo correcto después de la traducción de direcciones de Docker, en IPv4 e IPv6. Las conexiones abiertas antes del cierre también se cortan, con la herramienta conntrack si está instalada.
  • Los contenedores y tu red conservan el acceso. Un puerto cerrado nunca afecta a loopback ni a las direcciones privadas, entre ellas las redes de Docker, ni a nada que esté en tu lista blanca.
  • No deja sin acceso a los clientes habituales. El agente cuenta quién se conecta a estos puertos, a partir de la tabla de sockets y, para los puertos publicados por contenedores, de la tabla de conntrack. Mientras una dirección vista en 3 de los últimos 7 días no esté en la lista blanca, el puerto no se cierra (Clientes habituales).
  • Cada cambio se comprueba. El agente nunca cierra SSH, el 80, el 443 ni un puerto en el que escuche un servidor web, y deshace un cambio si SSH o un sitio deja de responder.

Sus reglas viven en sus propias cadenas y nunca edita las de Docker ni las tuyas. Si el iptables del sistema pasó al backend nf_tables mientras Docker sigue en el legacy, el agente mantiene su salto donde está la cadena de Docker hasta que Docker se reinicie.

Dos configuraciones no tienen cadena DOCKER-USER, así que ahí el agente no puede alcanzar los puertos publicados: Docker arrancado con "iptables": false y el backend nftables de Docker, experimental desde Docker 29. Los bloqueos siguen aplicándose a los servicios del propio host a través de INPUT.

Tráfico web en contenedores

Desde el agente 1.0.42, el firewall web lee, a través del socket de Docker o de Podman y en solo lectura:

  • los logs de acceso de los proxies inversos: Traefik (JSON o su formato por defecto, desde su archivo de log o su salida), Caddy (JSON) y HAProxy;
  • la salida de los servidores web en contenedores (imágenes de nginx, OpenResty, Apache httpd, WordPress, php:*-apache y LiteSpeed), cuando publican el puerto 80 o 443 o están detrás de un proxy cuyo log no se lee.

Detrás de un contenedor proxy, la dirección del visitante se toma de X-Forwarded-For solo en las peticiones que vienen del propio proxy. Detrás de Cloudflare, el visitante se toma de CF-Connecting-IP solo en las peticiones desde los rangos de Cloudflare, y una dirección de Cloudflare nunca se bloquea. La página del servidor muestra cada log leído en Red › Detección de ataques web, o por qué no se lee ninguno. Detalles: Logs de acceso de proxies inversos y contenedores.

Tres etiquetas te permiten ajustarlo por contenedor: infrafence.monitor (true o false), infrafence.log-path (rutas del host de sus logs) e infrafence.domain (sus dominios). Desde el agente 1.0.35, el agente también obtiene los dominios detrás de Traefik y Caddy a partir de sus etiquetas, así cada sitio puede llevar el distintivo de monitorización, verificado con un registro DNS TXT.

Instalación: en el host o como contenedor

En el host (recomendado): el comando de instalación del final de esta página, como root. Así el agente encuentra los contenedores web y lee sus etiquetas con la herramienta de línea de comandos docker. Si quieres, ejecuta antes la comprobación de solo lectura:

curl -fsSL https://github.com/infrafence/infrafence-agent/releases/latest/download/install.sh | sudo bash -s -- --dry-run

Como contenedor: la imagen ghcr.io/infrafence/infrafence-agent (también en Docker Hub como infrafence/infrafence-agent) es multiarquitectura y está firmada con cosign. Necesita la red y el espacio de nombres de procesos del host, privilegios para gestionar su firewall, y /var/log y el socket de Docker en solo lectura:

docker run -d --name infrafence-agent --restart unless-stopped \
  --privileged --network host --pid host \
  -v /var/log:/var/log:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v infrafence-config:/etc/infrafence \
  -e INFRAFENCE_TOKEN=<TOKEN> \
  ghcr.io/infrafence/infrafence-agent:latest

La imagen no incluye la herramienta de línea de comandos docker, así que dentro del contenedor indica al agente los logs en archivo con WEB_LOG_PATH; los logs de los proxies y la salida de los contenedores se siguen leyendo a través del socket. Docker Compose funciona igual, y un archivo de stack para Swarm ejecuta un agente por nodo. Todas las variables y montajes están en Docker.

Lo que no cubre

  • El tráfico entre contenedores del mismo host: nunca sale de las redes de Docker, y las direcciones privadas nunca se bloquean.
  • Las imágenes de los contenedores: la comprobación de vulnerabilidades cubre los paquetes instalados en el host, no lo que hay dentro de tus imágenes.
  • Los bloqueos, la lista blanca y los bloqueos por país se aplican a IPv4; los puertos cerrados, a IPv4 e IPv6.

Para un clúster en lugar de un solo host, consulta Detección de intrusiones en nodos Kubernetes. Para un servidor Coolify, consulta Proteger un servidor Coolify.

Pruébalo gratis en 1 servidor

Starter protege por completo un servidor, gratis y sin tarjeta de crédito.

  1. 01

    Crea una cuenta gratuita y abre Servidores › Añadir servidor para obtener el token de instalación. Es válido durante una hora.

    Crear el token
  2. 02

    Después ejecuta esto como root en el servidor:

    curl -fsSL https://github.com/infrafence/infrafence-agent/releases/latest/download/install.sh | sudo bash -s -- --token <TOKEN>