Sicurezza degli host Docker

Il traffico verso una porta pubblicata da un container viene inoltrato al container, non consegnato all'host, quindi passa dal percorso FORWARD. La documentazione di Docker lo dice chiaramente per ufw: i pacchetti vengono instradati prima che le regole del firewall possano essere applicate. Docker lascia una catena per le tue regole, DOCKER-USER, che valuta prima delle proprie.

Un firewall che scrive solo regole INPUT protegge quindi i servizi dell'host, non i container. Un container di database avviato con -p 3306:3306 è aperto al mondo anche se ufw nega la 3306.

• I ban arrivano ai container. Quando c'è Docker, l'agente salta alla propria catena INFRAFENCE da DOCKER-USER oltre che da INPUT, e tiene quel salto per primo. Ban, liste di minacce e blocchi per paese valgono quindi anche per le porte pubblicate dai container. Se un riavvio di Docker o un reload del firewall toglie il salto, l'agente lo rimette.
• Le porte dei database esposte si possono chiudere, anche quelle dei container. Una porta di database, cache o amministrazione aperta su internet (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch, l'API di Docker e le altre che l'agente conosce) si può chiudere dalla dashboard. La regola confronta la porta che il client ha chiesto (--ctorigdstport), che resta corretta anche dopo la traduzione degli indirizzi di Docker, su IPv4 e IPv6. Anche le connessioni aperte prima della chiusura vengono interrotte, con lo strumento conntrack quando è installato.
• Container e rete locale mantengono l'accesso. Loopback e indirizzi privati, comprese le reti Docker, non sono mai toccati da una porta chiusa, e nemmeno ciò che è nella tua whitelist.
• Non taglia fuori i client abituali. L'agente conta chi si connette a queste porte, dalla tabella dei socket e, per le porte pubblicate dai container, dalla tabella conntrack. Finché un indirizzo visto in 3 degli ultimi 7 giorni non è in whitelist, la porta non viene chiusa (Client abituali).
• Ogni modifica viene verificata. L'agente non chiude mai SSH, la 80, la 443 o una porta su cui ascolta un web server, e annulla una modifica se SSH o un sito smettono di rispondere.

Le sue regole stanno nelle sue catene, e non modifica mai le catene di Docker né le tue. Se l'iptables del sistema è passato al backend nf_tables mentre Docker gira ancora su quello legacy, l'agente tiene il suo salto dove si trova la catena di Docker, finché Docker non si riavvia.

Due configurazioni non hanno la catena DOCKER-USER, quindi lì l'agente non arriva alle porte pubblicate: Docker avviato con "iptables": false, e il backend nftables di Docker, sperimentale da Docker 29. I ban valgono comunque per i servizi dell'host, tramite INPUT.

Dall'agente 1.0.42 il web firewall legge, tramite il socket di Docker o Podman e in sola lettura:

• i log di accesso dei reverse proxy: Traefik (JSON o il suo formato predefinito, dal file di log o dall'output), Caddy (JSON) e HAProxy;
• l'output dei web server nei container (immagini nginx, OpenResty, Apache httpd, WordPress, php:*-apache e LiteSpeed), quando pubblicano la porta 80 o 443 o stanno dietro un proxy il cui log non viene letto.

Dietro un container proxy, l'indirizzo del visitatore viene preso da X-Forwarded-For solo per le richieste che arrivano dal proxy stesso. Dietro Cloudflare, il visitatore viene preso da CF-Connecting-IP solo per le richieste dagli intervalli di Cloudflare, e un indirizzo di Cloudflare non viene mai bannato. La pagina del server mostra ogni log letto in Rete › Rilevamento degli attacchi web, oppure perché non se ne legge nessuno. Dettagli: Log di accesso di reverse proxy e container.

Tre label ti permettono di regolarlo per container: infrafence.monitor (true o false), infrafence.log-path (i percorsi sull'host dei suoi log) e infrafence.domain (i suoi domini). Dall'agente 1.0.35 l'agente elenca anche i domini dietro Traefik e Caddy dalle loro label, così ogni sito può avere il badge di monitoraggio, verificato con un record DNS TXT.

Sull'host (consigliato): il comando di installazione in fondo a questa pagina, come root. L'agente trova così i container web e legge le loro label con lo strumento da riga di comando docker. Se vuoi, esegui prima il controllo in sola lettura:

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

Come container: l'immagine ghcr.io/infrafence/infrafence-agent (anche su Docker Hub come infrafence/infrafence-agent) è multi-architettura e firmata con cosign. Ha bisogno della rete e dello spazio dei processi dell'host, dei privilegi per gestire il firewall dell'host, e di /var/log e del socket di Docker in sola lettura:

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

L'immagine non contiene lo strumento da riga di comando docker, quindi dentro il container indica all'agente i file di log con WEB_LOG_PATH; i log dei proxy e l'output dei container vengono comunque letti tramite il socket. Docker Compose funziona allo stesso modo, e uno stack file per Swarm avvia un agente per nodo. Tutte le variabili e i mount sono in Docker.

• Il traffico tra container sullo stesso host: non esce mai dalle reti Docker, e gli indirizzi privati non vengono mai bannati.
• Le immagini dei container: il controllo delle vulnerabilità riguarda i pacchetti installati sull'host, non il contenuto delle tue immagini.
• Ban, whitelist e blocchi per paese valgono per IPv4; le porte chiuse per IPv4 e IPv6.

Per un cluster invece di un singolo host, vedi Rilevamento delle intrusioni sui nodi Kubernetes. Per un server Coolify, vedi Proteggere un server Coolify.