ZFW est un pare-feu communautaire pour hôte conçu pour ZimaOS, et non une fonctionnalité intégrée par IceWhale. Il s’installe comme une extension système au niveau de l’hôte, apparaît sous forme de tuile dans le tableau de bord et tente de résoudre une lacune réelle de ZimaOS : les services natifs et les ports publiés par Docker peuvent être accessibles sur le réseau local, à moins qu’un autre pare-feu ou un équipement réseau en amont ne les restreigne.
La publication source commençait avec ZFW v1.0.10, mais cette version n’est plus la bonne référence pour une installation actuelle. ZFW a continué d’évoluer rapidement à mesure que ZimaOS lui-même changeait. La version amont actuelle est v1.0.25, et le projet a déjà corrigé des problèmes de compatibilité liés au nf_tables backend, des modifications des jetons de session de ZimaOS 1.7.x, de l’exposition IPv6 de Docker et du trafic Zima Net sur tun0.
ZFW est un logiciel communautaire, pas un pare-feu d’IceWhale
Lintux a développé et maintient ZFW de manière indépendante. Le fil de discussion source contient de nombreux tests effectués par la communauté, notamment par des utilisateurs ayant confirmé la persistance des règles, le blocage des ports, le fonctionnement du retour en arrière et les correctifs de compatibilité ultérieurs, mais aucune annonce d’IceWhale ne fait de ZFW un pare-feu officiel de ZimaOS.
Cette distinction est importante, car ZFW manipule directement la pile réseau de l’hôte. Une règle incorrecte ou incompatible peut bloquer SSH, l’interface Web, les applications Docker ou l’accès à distance.
ZFW sépare les services de l’hôte des ports publiés par Docker
l’architecture de ZFW reconnaît que le trafic Docker diffère du trafic INPUT ordinaire de l’hôte :
- les services natifs de ZimaOS ou de l’hôte sont contrôlés par des règles de type INPUT ;
- Les ports publiés par Docker sont filtrés via
DOCKER-USER; - IPv6 possède ses propres chaînes et son propre comportement correspondants.
C’est plus précis qu’un tutoriel sur les pare-feu qui vérifie uniquement INPUT et suppose que Docker suit le même chemin.
L’application sécurisée est la fonctionnalité de sécurité la plus importante
Le projet a introduit un retour en arrière de sécurité après 120 secondes. Lorsqu’un ensemble de règles est appliqué, l’utilisateur doit le confirmer avant l’expiration du délai. Si les règles bloquent accidentellement l’accès, le pare-feu annule automatiquement les modifications.
C’est particulièrement utile sur un NAS sans écran ni clavier, car une erreur de configuration du pare-feu peut sinon nécessiter une intervention locale avec écran et clavier pour récupérer l’accès.
Le fil de discussion a révélé une véritable faille de type « autoriser par défaut » pour le terminal ZimaOS
Un utilisateur a signalé que ZFW bloquait le port TCP 7681, le port par défaut du terminal ttyd. Lintux a expliqué que la liste blanche initiale comprenait des ports tels que SSH, HTTP/HTTPS, SMB et plusieurs services de ZimaOS, mais pas le port 7681.
C’est un rappel utile : avant d’activer une politique de refus par défaut, répertoriez les services dont vous dépendez réellement. Un pare-feu peut fonctionner correctement tout en bloquant un service oublié par le profil par défaut.
ZimaOS 1.6.2 a modifié le backend d’iptables
L’une des mises à jour les plus importantes du fil source est survenue après que ZimaOS 1.6.2 a fait basculer le chemin iptables effectivement utilisé par Docker vers nf_tables backend. Les anciennes versions de ZFW pouvaient écrire les règles dans l’ancienne table inutilisée, alors que la tuile semblait toujours correcte.
Les versions ultérieures ont ajouté la détection du backend et une validation supplémentaire des règles Docker. C’est pourquoi les anciennes instructions d’installation de ZFW ne doivent jamais être figées comme une procédure permanente.
Le fil de discussion a révélé et corrigé une véritable condition de contournement du pare-feu Docker
Lors des tests de la v1.0.16, un utilisateur a découvert que DOCKER-USER pouvait se terminer par un simple RETURN sans les règles de refus par défaut attendues. Lintux a confirmé qu’il s’agissait d’un véritable chemin inattendu de type « fail-open » et a modifié la logique d’inventaire des ports.
Par la suite, le même utilisateur a réinstallé la v1.0.19, réappliqué le pare-feu et vérifié que les règles attendues par port ainsi que la gestion de l’UDP étaient présentes.
IPv6 a nécessité plusieurs séries de corrections en conditions réelles
Le fil de discussion source documente des cas où la protection IPv6 était active, mais signalée de manière incorrecte, ainsi que d’autres cas où des ports IPv6 publiés par Docker étaient bloqués de manière inattendue. Il ne s’agissait pas de problèmes théoriques : des utilisateurs ont publié la sortie réelle des chaînes et le mainteneur a reproduit et corrigé des chemins précis.
Pour une connexion domestique compatible IPv6, testez l’accès depuis un véritable réseau IPv6 externe plutôt que de supposer qu’un test IPv4 sur le réseau local démontre la même politique.
La version actuelle de ZFW a également dû s’adapter à l’accès à distance de Zima Net
Une version ultérieure du projet en amont a révélé que le trafic d’accès à distance de Zima Net, intégré à ZimaOS, sur tun0 pouvait être supprimé par les anciennes versions de ZFW. ZFW v1.0.24 a ajouté la gestion nécessaire du contournement dans les chaînes concernées.
C’est une autre raison de mettre à jour ZimaOS et ZFW ensemble, puis de vérifier l’accès à distance après une mise à niveau du pare-feu.
Utilisez la version actuelle de ZFW, pas la v1.0.10
En septembre 2026, la version v1.0.25 de ZFW est la dernière version répertoriée par le projet en amont. Consultez les versions actuelles de ZFW et l’historique de compatibilité avant toute installation ou mise à jour.
Vérifiez le pare-feu actif, pas seulement la tuile verte du tableau de bord
Après avoir activé ZFW, testez :
- SSH et l’interface Web depuis le réseau local ;
- le terminal de ZimaOS ;
- les ports importants publiés par Docker ;
- Tailscale/ZeroTier/Zima Net, s’ils sont utilisés ;
- IPv6 depuis l’extérieur du réseau local, le cas échéant ;
- persistance après redémarrage.
L’historique des sources montre pourquoi une interface utilisateur en apparence saine ne doit pas être la seule preuve que les règles ont bien atteint le backend actif.
FAQ de ZFW
ZFW est-il le pare-feu officiel d’IceWhale ?
Non. Il s’agit d’un module de pare-feu communautaire pour l’hôte, qui s’intègre étroitement à ZimaOS.
Les utilisateurs actuels doivent-ils installer la version v1.0.10 du billet d’origine ?
Non. Le projet a reçu de nombreuses corrections de compatibilité et de sécurité depuis cette version.
Pourquoi ZFW utilise-t-il DOCKER-USER ?
Le trafic publié par Docker peut contourner le filtrage INPUT classique de l’hôte ; ZFW utilise donc le chemin de filtrage dédié de Docker pour les ports des conteneurs.
