Segurança de hosts Docker

O tráfego para uma porta publicada de um container é encaminhado ao container, não entregue ao host, então passa pelo caminho FORWARD. A documentação do Docker diz isso com todas as letras sobre o ufw: os pacotes são roteados antes que as regras do firewall possam ser aplicadas. O Docker deixa uma cadeia para as suas próprias regras, a DOCKER-USER, que ele avalia antes das dele.

Ou seja, um firewall que só escreve regras de INPUT protege os serviços do próprio host, não os containers. Um container de banco de dados iniciado com -p 3306:3306 fica aberto para o mundo mesmo que o ufw negue a 3306.

• Os bloqueios chegam aos containers. Quando há Docker, o agente salta para a própria cadeia INFRAFENCE a partir de DOCKER-USER, além de INPUT, e mantém esse salto em primeiro lugar. Os bloqueios, as listas de ameaças e os bloqueios por país valem, portanto, também para as portas publicadas por containers. Se um reinício do Docker ou um reload do firewall remove o salto, o agente o coloca de volta.
• Portas de banco de dados expostas podem ser fechadas, inclusive de containers. Uma porta de banco de dados, cache ou administração aberta para a internet (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch, a API do Docker e as outras que o agente conhece) pode ser fechada pelo painel. A regra confere a porta que o cliente pediu (--ctorigdstport), que continua correta depois da tradução de endereços do Docker, em IPv4 e IPv6. As conexões abertas antes do fechamento também são derrubadas, com a ferramenta conntrack quando ela está instalada.
• Os containers e a sua rede continuam com acesso. Loopback e endereços privados, entre eles as redes do Docker, nunca são afetados por uma porta fechada, nem nada que esteja na sua lista de permissões.
• Ele não corta os clientes habituais. O agente conta quem se conecta a essas portas, pela tabela de sockets e, para as portas publicadas por containers, pela tabela do conntrack. Enquanto um endereço visto em 3 dos últimos 7 dias não estiver na lista de permissões, a porta não é fechada (Clientes habituais).
• Toda mudança é verificada. O agente nunca fecha o SSH, a 80, a 443 nem uma porta em que um servidor web escuta, e desfaz uma mudança se o SSH ou um site parar de responder.

As regras dele ficam nas próprias cadeias, e ele nunca altera as cadeias do Docker nem as suas. Se o iptables do sistema passou para o backend nf_tables enquanto o Docker ainda roda no legado, o agente mantém o salto onde está a cadeia do Docker até o Docker reiniciar.

Duas configurações não têm a cadeia DOCKER-USER, então ali o agente não alcança as portas publicadas: o Docker iniciado com "iptables": false e o backend nftables do Docker, experimental desde o Docker 29. Os bloqueios continuam valendo para os serviços do próprio host, pelo INPUT.

A partir do agente 1.0.42, o firewall web lê, pelo socket do Docker ou do Podman e só em leitura:

• os logs de acesso dos proxies reversos: Traefik (JSON ou o formato padrão dele, do arquivo de log ou da saída), Caddy (JSON) e HAProxy;
• a saída dos servidores web em containers (imagens nginx, OpenResty, Apache httpd, WordPress, php:*-apache e LiteSpeed), quando publicam a porta 80 ou 443 ou ficam atrás de um proxy cujo log não é lido.

Atrás de um container de proxy, o endereço do visitante é tirado de X-Forwarded-For só nas requisições que vêm do próprio proxy. Atrás do Cloudflare, o visitante é tirado de CF-Connecting-IP só nas requisições vindas das faixas do Cloudflare, e um endereço do Cloudflare nunca é bloqueado. A página do servidor mostra cada log lido em Rede › Detecção de ataques web, ou por que nenhum é lido. Detalhes: Logs de acesso de proxies reversos e containers.

Três labels permitem ajustar isso por container: infrafence.monitor (true ou false), infrafence.log-path (caminhos dos logs no host) e infrafence.domain (os domínios dele). A partir do agente 1.0.35, o agente também lista os domínios atrás do Traefik e do Caddy pelos labels deles, para cada site poder receber o selo de monitoramento, verificado com um registro DNS TXT.

No host (recomendado): o comando de instalação no fim desta página, como root. O agente então encontra os containers web e lê os labels deles com a ferramenta de linha de comando docker. Se quiser, rode antes a verificação somente leitura:

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

Como container: a imagem ghcr.io/infrafence/infrafence-agent (também no Docker Hub como infrafence/infrafence-agent) é multiarquitetura e assinada com cosign. Ela precisa da rede e do namespace de processos do host, de privilégios para gerenciar o firewall do host e de /var/log e do socket do Docker em somente leitura:

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

A imagem não tem a ferramenta de linha de comando docker, então, dentro do container, aponte o agente para os logs em arquivo com WEB_LOG_PATH; os logs dos proxies e a saída dos containers continuam sendo lidos pelo socket. O Docker Compose funciona do mesmo jeito, e um arquivo de stack para Swarm roda um agente por nó. Todas as variáveis e montagens estão em Docker.

• O tráfego entre containers no mesmo host: ele nunca sai das redes do Docker, e endereços privados nunca são bloqueados.
• As imagens dos containers: a verificação de vulnerabilidades cobre os pacotes instalados no host, não o que está dentro das suas imagens.
• Os bloqueios, a whitelist e os bloqueios por país valem para IPv4; as portas fechadas, para IPv4 e IPv6.

Para um cluster em vez de um único host, veja Detecção de intrusão em nós Kubernetes. Para um servidor Coolify, veja Como proteger um servidor Coolify.