ZFW è un firewall dell’host sviluppato dalla community per ZimaOS, non una funzione integrata di IceWhale. Si installa come estensione di sistema a livello host, appare come riquadro nella dashboard e cerca di risolvere una lacuna reale di ZimaOS: i servizi nativi e le porte pubblicate da Docker possono essere raggiungibili attraverso la LAN, a meno che un altro firewall o un dispositivo di rete a monte non ne limiti l’accesso.
Il post originale iniziava con ZFW v1.0.10, ma questa versione non è più il riferimento corretto per un’installazione attuale. ZFW ha continuato a cambiare rapidamente con l’evoluzione di ZimaOS. La versione upstream attuale è la v1.0.25 e il progetto ha già risolto problemi di compatibilità relativi al nf_tables backend, modifiche ai token di sessione di ZimaOS 1.7.x, esposizione IPv6 di Docker e traffico Zima Net su tun0.
ZFW è un software della community, non un firewall di IceWhale
Lintux ha sviluppato e mantiene ZFW in modo indipendente. La discussione originale contiene numerosi test della community, inclusi utenti che hanno confermato la persistenza delle regole, il blocco delle porte, il comportamento del rollback e successive correzioni di compatibilità, ma nessun annuncio di IceWhale rende ZFW un firewall ufficiale di ZimaOS.
Questa distinzione è importante perché ZFW manipola direttamente lo stack di rete dell’host. Una regola errata o incompatibile può bloccare SSH, la WebUI, le app Docker o l’accesso remoto.
ZFW separa i servizi dell’host dalle porte pubblicate da Docker
l’architettura di ZFW riconosce che il traffico Docker è diverso dal normale traffico INPUT dell’host:
- i servizi nativi di ZimaOS/host sono controllati tramite regole di tipo INPUT;
- Le porte pubblicate da Docker vengono filtrate tramite
DOCKER-USER; - IPv6 dispone di catene e comportamenti corrispondenti propri.
Questo è più accurato di un tutorial sul firewall che controlla solo INPUT e presume che Docker segua lo stesso percorso.
L’applicazione sicura è la funzione di protezione più importante
Il progetto ha introdotto un rollback automatico di sicurezza dopo 120 secondi. Quando viene applicato un set di regole, l’utente deve confermarlo prima che scada il timer. Se le regole bloccano accidentalmente l’accesso dell’utente, il firewall ripristina automaticamente la configurazione precedente.
Questo è particolarmente importante su un NAS headless, perché un errore del firewall potrebbe altrimenti trasformarsi in un intervento di ripristino con monitor e tastiera collegati localmente.
La discussione ha messo in luce una vera lacuna nella configurazione predefinita di autorizzazione del terminale ZimaOS
Un utente ha segnalato che ZFW bloccava la porta TCP 7681, la porta predefinita del terminale ttyd. Lintux ha spiegato che la whitelist iniziale originale includeva porte come SSH, HTTP/HTTPS, SMB e diversi servizi ZimaOS, ma non la 7681.
Questo è un utile promemoria: prima di abilitare un criterio di negazione predefinita, fai l’inventario dei servizi su cui fai effettivamente affidamento. Un firewall può funzionare correttamente e bloccare comunque un servizio che il profilo predefinito ha dimenticato.
ZimaOS 1.6.2 ha modificato il backend di iptables
Uno degli aggiornamenti più importanti del thread originale è arrivato dopo che ZimaOS 1.6.2 aveva spostato il percorso iptables effettivo di Docker verso nf_tables backend. Le versioni precedenti di ZFW potevano scrivere le regole nella tabella legacy inutilizzata, mentre il riquadro continuava ad apparire funzionante.
Le versioni successive hanno aggiunto il rilevamento del backend e ulteriori verifiche delle regole Docker. Per questo le vecchie istruzioni di installazione di ZFW non dovrebbero mai essere congelate come procedura permanente.
Il thread ha individuato e risolto una reale condizione di fail-open di Docker
Durante i test della v1.0.16, un utente ha scoperto che DOCKER-USER poteva terminare con un semplice RETURN senza le regole predefinite di negazione previste. Lintux ha confermato che si trattava di un percorso reale e imprevisto di fail-open e ha modificato la logica di inventario delle porte.
In seguito, lo stesso utente ha reinstallato la v1.0.19, riapplicato il firewall e verificato che fossero presenti le regole previste per ogni porta e la gestione UDP.
IPv6 ha richiesto diverse tornate di correzioni basate sull’uso reale
Il thread originale documenta casi in cui la protezione IPv6 era attiva ma veniva segnalata in modo errato, oltre ad altri casi in cui le porte IPv6 pubblicate da Docker venivano bloccate inaspettatamente. Non erano problemi teorici: gli utenti hanno pubblicato l’output delle catene in tempo reale e il manutentore ha riprodotto e corretto percorsi specifici.
Per una connessione domestica compatibile con IPv6, verifica l’accesso da una vera rete IPv6 esterna invece di presumere che un test IPv4 dalla LAN dimostri la stessa policy.
Anche ZFW attuale ha dovuto adattarsi all’accesso remoto Zima Net
Una versione upstream successiva ha rilevato che il traffico di accesso remoto Zima Net integrato in ZimaOS su tun0 potrebbe essere scartato dalle versioni precedenti di ZFW. ZFW v1.0.24 ha aggiunto la gestione necessaria per il bypass nelle catene interessate.
Questo è un ulteriore motivo per aggiornare insieme ZimaOS e ZFW e verificare l’accesso remoto dopo un aggiornamento del firewall.
Usa la versione corrente di ZFW, non la v1.0.10
A settembre 2026, l’upstream indica ZFW v1.0.25 come versione più recente. Consulta le versioni correnti di ZFW e la cronologia della compatibilità prima di installare o aggiornare.
Verifica il firewall attivo, non solo il riquadro verde del dashboard
Dopo aver abilitato ZFW, verifica:
- SSH e la WebUI dalla LAN;
- il terminale di ZimaOS;
- le porte importanti pubblicate da Docker;
- Tailscale/ZeroTier/Zima Net, se utilizzati;
- IPv6 dall’esterno della LAN, se pertinente;
- persistenza dopo il riavvio.
La cronologia del codice sorgente mostra perché un’interfaccia apparentemente funzionante non dovrebbe essere l’unica prova che le regole siano state applicate al backend attivo.
Domande frequenti su ZFW
ZFW è un firewall ufficiale di IceWhale?
No. È un modulo firewall per host sviluppato dalla community, integrato profondamente con ZimaOS.
Gli utenti attuali devono installare la v1.0.10 del post originale?
No. Da quella versione, il progetto ha ricevuto numerose correzioni di compatibilità e sicurezza.
Perché ZFW usa DOCKER-USER?
Il traffico pubblicato da Docker può bypassare il normale filtraggio INPUT dell’host, quindi ZFW utilizza il percorso di filtraggio dedicato di Docker per le porte dei container.
