コミュニティソリューション

ZimaOSのZFWホストファイアウォール:安全な適用、Dockerフィルタリング、IPv6、現在の互換性

A May-July 2026 community module thread introducing ZFW as a ZimaOS dashboard firewall with host INPUT filtering, Docker DOCKER-USER rules, IPv6 handling, exposure visibility, and a 120-second Safe-Apply rollback. The thread documents multiple real compatibility bugs and fixes as ZimaOS moved from legacy iptables to nf_tables.

ZFWはZimaOS向けのコミュニティ開発ホストファイアウォールであり、IceWhaleの組み込み機能ではありません。ホストレベルのシステム拡張機能としてインストールされ、ダッシュボードタイルとして表示されます。また、別のファイアウォールや上流のネットワーク機器による制限がない限り、ネイティブサービスやDocker公開ポートがLAN全体から到達可能になるという、ZimaOSの実際の問題の解決を試みます。

元の投稿はZFW v1.0.10から始まっていましたが、現在のインストールにおける適切な参照先はもはやそのバージョンではありません。ZimaOS自体の変更に伴い、ZFWも急速に変化し続けました。現在のアップストリームリリースはv1.0.25で、プロジェクトではすでにZimaOS 1.6.2の互換性問題を修正しています。 nf_tables バックエンド、ZimaOS 1.7.xのセッショントークン変更、IPv6のDocker公開、Zima Netのトラフィックに関する tun0.

アクティブ状態、公開ポート、ブロックされたポート、検出結果、安全な適用の操作を表示する、ZimaOS上のZFWファイアウォールダッシュボード
ZFWは、ZimaOS風のダッシュボードにファイアウォールの状態、公開ポート数、デッドマンロールバックの操作を統合します。

ZFWはコミュニティ製ソフトウェアであり、IceWhaleのファイアウォールではない

LintuxはZFWを独立して開発・保守しています。元のスレッドには、ルールの永続化、ブロックされたポート、ロールバック動作、後の互換性修正を確認したユーザーを含む、コミュニティによる充実したテスト結果が掲載されています。ただし、IceWhaleによる発表がない限り、ZFWが公式のZimaOSファイアウォールになるわけではありません。

この違いが重要なのは、ZFWがホストのネットワークスタックを直接操作するためです。不適切または互換性のないルールによって、SSH、WebUI、Dockerアプリ、リモートアクセスがブロックされる可能性があります。

ZFWはホストサービスとDocker公開ポートを分離する

ZFWのアーキテクチャは、Dockerのトラフィックが通常のホストINPUTトラフィックとは異なることを認識しています。

  • ネイティブのZimaOS/ホストサービスは、INPUT形式のルールによって制御されます。
  • Dockerが公開するポートは、次を通じてフィルタリングされます DOCKER-USER;
  • IPv6には、それに対応する独自のチェーンと動作があります。

これは、INPUTだけを確認し、Dockerも同じ経路に従うと想定するファイアウォール解説より正確です。

安全な適用機能が最も重要な安全機能

このソースでは、120秒後に自動ロールバックするデッドマン機構が導入されました。ルールセットを適用すると、タイマーが切れる前にユーザーが確認する必要があります。ルールによって誤って締め出された場合、ファイアウォールは自動的にロールバックします。

ヘッドレスNASでは特に重要です。ファイアウォールの設定ミスが、ローカルモニターとキーボードを使った復旧作業につながる可能性があるためです。

このスレッドは、ZimaOSターミナルにおける実際のデフォルト許可の抜け穴を明らかにした

あるユーザーが、ZFWによってデフォルトのttydターミナルポートであるTCP 7681がブロックされたと報告しました。Lintuxは、当初のスターターホワイトリストにはSSH、HTTP/HTTPS、SMB、その他いくつかのZimaOSサービスのポートが含まれていたものの、7681は含まれていなかったと説明しました。

これは有用な注意喚起です。デフォルト拒否ポリシーを有効にする前に、実際に依存しているサービスを一覧化しましょう。ファイアウォールが正しく動作していても、デフォルトプロファイルに含まれていないサービスをブロックすることがあります。

ZimaOS 1.6.2でiptablesバックエンドが変更

ソーススレッドで最も重要な更新の一つは、ZimaOS 1.6.2でDockerの実効iptables経路が次のものに切り替わった後に行われました。 nf_tables バックエンド。古いZFWビルドでは、タイルが正常に見えていても、使用されていないレガシーテーブルにルールを書き込む可能性がありました。

後続のリリースでは、バックエンド検出と追加のDockerルール検証が導入されました。そのため、古いZFWのインストール手順を恒久的な手順として固定すべきではありません。

スレッドで実際のDockerのフェイルオープン状態が発見され、修正された

v1.0.16のテスト中、あるユーザーが次のことを発見しました: DOCKER-USER 期待されるデフォルト拒否ルールのない、単純なRETURNで終わる可能性がありました。Lintuxは、これが予期しない実際のフェイルオープン経路であることを確認し、ポートインベントリのロジックを変更しました。

その後、同じユーザーがv1.0.19を再インストールし、ファイアウォールを再適用したところ、期待されるポートごとのルールとUDP処理が存在することを確認しました。

IPv6には実環境での複数回の修正が必要だった

ソーススレッドには、IPv6保護が有効なのに誤って報告されたケースや、Dockerが公開したIPv6ポートが予期せずブロックされたケースが記録されています。これらは理論上の懸念ではなく、ユーザーが稼働中のチェーン出力を投稿し、メンテナーが特定の経路を再現して修正しました。

IPv6に対応した家庭用接続では、IPv4のLANテストで同じポリシーが証明されると想定せず、実際の外部IPv6ネットワークからのアクセスをテストしてください。

現行のZFWはZima Netのリモートアクセスにも対応する必要があった

その後の上流リリースで、ZimaOSに組み込まれたZima Netのリモートアクセス用トラフィックが、上の tun0 古いZFWビルドでは削除される可能性がありました。ZFW v1.0.24では、関連するすべてのチェーンに必要なバイパス処理が追加されました。

これも、ZimaOSとZFWの両方を同時に更新し、ファイアウォールのアップグレード後にリモートアクセスを確認すべき理由です。

v1.0.10ではなく、現在のZFWリリースを使用する

2026年9月時点で、上流ではZFW v1.0.25が最新リリースとして掲載されています。インストールまたは更新する前に、現在のZFWリリースと互換性の履歴を確認してください。

緑色のダッシュボードタイルだけでなく、稼働中のファイアウォールを確認する

ZFWを有効にした後、次をテストします:

  • LANからのSSHとWebUI;
  • ZimaOSターミナル;
  • 重要なDocker公開ポート;
  • 使用している場合はTailscale/ZeroTier/Zima Net;
  • 必要に応じて、LAN外部からのIPv6;
  • 再起動後の永続性。

ソース履歴から、正常に見えるUIだけでは、ルールが稼働中のバックエンドに反映されたことの唯一の証拠にはならない理由が分かります。

ZFWに関するよくある質問

ZFWはIceWhale公式のファイアウォールですか?

いいえ。ZimaOSと緊密に統合する、コミュニティ製のホストファイアウォールモジュールです。

現在のユーザーは、元の投稿にあるv1.0.10をインストールすべきですか?

いいえ。そのバージョン以降、プロジェクトには互換性とセキュリティに関する多くの修正が加えられています。

ZFWはなぜDOCKER-USERを使用するのですか?

Dockerが公開したトラフィックは通常のホストINPUTフィルタリングを迂回できるため、ZFWはコンテナポート専用のフィルタリング経路を使用します。