ZFW ist eine von der Community entwickelte Host-Firewall für ZimaOS, keine integrierte Funktion von IceWhale. Sie wird als systemweite Host-Erweiterung installiert, erscheint als Dashboard-Kachel und versucht, eine echte Lücke in ZimaOS zu schließen: Native Dienste und von Docker veröffentlichte Ports können im LAN erreichbar sein, sofern sie nicht durch eine andere Firewall oder ein vorgeschaltetes Netzwerkgerät eingeschränkt werden.
Der Quellbeitrag begann mit ZFW v1.0.10, doch diese Version ist für eine aktuelle Installation nicht mehr die richtige Referenz. ZFW wurde weiter schnell verändert, während sich auch ZimaOS weiterentwickelte. Die aktuelle Upstream-Version ist v1.0.25, und das Projekt hat bereits Kompatibilitätsprobleme im Zusammenhang mit dem nf_tables Backend, Änderungen an Sitzungstokens in ZimaOS 1.7.x, IPv6-Docker-Exponierung und Zima-Net-Datenverkehr auf tun0.
ZFW ist Community-Software, keine IceWhale-Firewall
Lintux hat ZFW unabhängig entwickelt und pflegt es eigenständig. Der Quellthread enthält umfangreiche Tests durch die Community, darunter Nutzerbestätigungen zur Persistenz von Regeln, zu blockierten Ports, zum Rollback-Verhalten und zu späteren Kompatibilitätskorrekturen. Eine Ankündigung von IceWhale macht ZFW jedoch nicht zu einer offiziellen ZimaOS-Firewall.
Diese Unterscheidung ist wichtig, weil ZFW den Netzwerk-Stack des Hosts direkt verändert. Eine fehlerhafte oder inkompatible Regel kann SSH, die WebUI, Docker-Apps oder den Fernzugriff blockieren.
ZFW trennt Host-Dienste von durch Docker veröffentlichten Ports
Die Architektur von ZFW berücksichtigt, dass Docker-Datenverkehr sich vom gewöhnlichen INPUT-Datenverkehr des Hosts unterscheidet:
- native ZimaOS-/Host-Dienste werden über INPUT-ähnliche Regeln gesteuert;
- Von Docker veröffentlichte Ports werden gefiltert durch
DOCKER-USER; - IPv6 verfügt über eigene entsprechende Ketten und eigenes Verhalten.
Das ist genauer als ein Firewall-Tutorial, das nur INPUT prüft und davon ausgeht, dass Docker denselben Pfad verwendet.
Sicheres Anwenden ist die wichtigste Sicherheitsfunktion
Die Quelle führte einen 120-sekündigen Dead-Man-Rollback ein. Wenn ein Regelsatz angewendet wird, muss der Nutzer ihn bestätigen, bevor der Timer abläuft. Falls die Regeln den Nutzer versehentlich aussperren, setzt die Firewall sie automatisch zurück.
Das ist besonders bei einem NAS ohne Bildschirm und Tastatur wertvoll, denn ein Firewall-Fehler kann andernfalls dazu führen, dass eine Wiederherstellung über einen lokalen Monitor und eine Tastatur erforderlich wird.
Der Thread legte eine echte Lücke bei der standardmäßigen Zulassung für das ZimaOS-Terminal offen
Ein Nutzer berichtete, dass ZFW TCP-Port 7681, den standardmäßigen ttyd-Terminalport, blockiert hat. Lintux erklärte, dass die ursprüngliche Starter-Whitelist Ports wie SSH, HTTP/HTTPS, SMB und mehrere ZimaOS-Dienste enthielt, nicht jedoch 7681.
Dies ist eine nützliche Erinnerung: Erfassen Sie vor der Aktivierung einer standardmäßigen Verweigerungsrichtlinie die Dienste, auf die Sie tatsächlich angewiesen sind. Eine Firewall kann korrekt funktionieren und trotzdem einen Dienst blockieren, den das Standardprofil nicht berücksichtigt hat.
ZimaOS 1.6.2 hat das iptables-Backend geändert
Eine der wichtigsten Aktualisierungen im Quellthread erfolgte, nachdem ZimaOS 1.6.2 den effektiven iptables-Pfad von Docker auf den nf_tables Backend. Ältere ZFW-Versionen konnten Regeln in die nicht verwendete ältere Tabelle schreiben, während die Kachel weiterhin fehlerfrei aussah.
Die späteren Versionen fügten eine Backend-Erkennung und zusätzliche Validierung der Docker-Regeln hinzu. Deshalb sollten alte ZFW-Installationsanleitungen niemals als dauerhaft gültige Vorgehensweise unverändert übernommen werden.
Der Thread fand eine echte Docker-Fail-Open-Bedingung und behob sie
Beim Testen von v1.0.16 stellte ein Benutzer fest, dass DOCKER-USER konnte mit einem einfachen RETURN ohne die erwarteten standardmäßigen DENY-Regeln enden. Lintux bestätigte, dass dies ein echter, unerwarteter Fail-Open-Pfad war, und änderte die Logik zur Portinventarisierung.
Später installierte derselbe Benutzer v1.0.19 erneut, wendete die Firewall erneut an und bestätigte, dass die erwarteten Regeln pro Port und die UDP-Behandlung vorhanden waren.
IPv6 erforderte mehrere Runden praxisnaher Korrekturen
Der Quellthread dokumentiert Fälle, in denen der IPv6-Schutz aktiv war, aber falsch gemeldet wurde, sowie andere Fälle, in denen von Docker veröffentlichte IPv6-Ports unerwartet blockiert wurden. Dies waren keine theoretischen Probleme; Benutzer veröffentlichten die Ausgabe aktiver Chains, und der Maintainer reproduzierte und behob die spezifischen Pfade.
Teste bei einer IPv6-fähigen Heimverbindung den Zugriff über ein echtes externes IPv6-Netzwerk, anstatt anzunehmen, dass ein IPv4-LAN-Test dieselbe Richtlinie bestätigt.
Auch das aktuelle ZFW musste sich an den Zima-Net-Fernzugriff anpassen
Eine spätere Upstream-Version stellte fest, dass der integrierte Zima-Net-Fernzugriffsverkehr von ZimaOS auf tun0 konnte von älteren ZFW-Versionen verworfen werden. ZFW v1.0.24 fügte die erforderliche Umgehungsbehandlung in den relevanten Chains hinzu.
Dies ist ein weiterer Grund, ZimaOS und ZFW gemeinsam zu aktualisieren und den Fernzugriff nach einem Firewall-Upgrade zu überprüfen.
Verwende die aktuelle ZFW-Version, nicht v1.0.10
Im September 2026 führt Upstream ZFW v1.0.25 als neueste Version. Prüfe die aktuellen ZFW-Versionen und den Kompatibilitätsverlauf, bevor du installierst oder aktualisierst.
Überprüfe die aktive Firewall, nicht nur die grüne Dashboard-Kachel
Teste nach der Aktivierung von ZFW:
- SSH und die WebUI aus dem LAN;
- das ZimaOS-Terminal;
- wichtige von Docker veröffentlichte Ports;
- Tailscale/ZeroTier/Zima Net, sofern verwendet;
- IPv6 von außerhalb des LANs, sofern relevant;
- Persistenz nach einem Neustart.
Der Quellverlauf zeigt, warum eine scheinbar fehlerfreie Benutzeroberfläche nicht der einzige Beleg dafür sein sollte, dass die Regeln das aktive Backend erreicht haben.
ZFW-FAQ
Ist ZFW eine offizielle IceWhale-Firewall?
Nein. Es handelt sich um ein Community-Modul für die Host-Firewall, das sich tief in ZimaOS integriert.
Sollten aktuelle Benutzer v1.0.10 aus dem ursprünglichen Beitrag installieren?
Nein. Das Projekt hat seit dieser Version viele Kompatibilitäts- und Sicherheitskorrekturen erhalten.
Warum verwendet ZFW DOCKER-USER?
Von Docker veröffentlichter Datenverkehr kann die gewöhnliche INPUT-Filterung des Hosts umgehen. Daher verwendet ZFW den dedizierten Filterpfad von Docker für Container-Ports.
