ufw と firewalld の比較｜仕組み・コマンド・向いている環境の違い

ufw と firewalld は、どちらも Linux カーネルのパケットフィルター（netfilter）を扱いやすくするための管理ツールです。結論から言うと、Ubuntu／Debian 系で1台のサーバーを単純なルールで守るなら ufw、RHEL／AlmaLinux／Rocky Linux／Fedora 系やゾーンで用途を分けたい環境なら firewalld が素直な選択です。この記事では、両者の設計の違い、同じ作業をしたときのコマンドの違い、運用でつまずきやすい点を比べ、自分の環境でどちらを使うべきか判断できるようにします。

共通点：どちらも netfilter のフロントエンド

ufw も firewalld も、自分でパケットを処理するわけではありません。実際のフィルタリングはカーネルの netfilter が行い、ufw や firewalld はそのルールを分かりやすい形で作成・保存する役割を持ちます。

• ufw（Uncomplicated Firewall）：iptables のルールを生成する。最近の Ubuntu では iptables コマンド自体が nftables 互換の実装（iptables-nft）になっていることが多い
• firewalld：デーモンとして常駐し、RHEL 8 以降などでは nftables をバックエンドとして使う

このため、同じサーバーで両方を有効にしたり、どちらかを使いながら iptables や nft コマンドで直接ルールを足したりすると、ルールが二重管理になり、再起動や再読み込みのたびに状態が変わる原因になります。使うツールは1つに決めるのが大原則です。

設計の違い

いちばん大きな違いは ゾーン と runtime／permanent の分離 です。ufw は「ルールを足せばすぐ効いて、再起動後も残る」ので直感的です。firewalld は「まず runtime で試し、問題なければ permanent に書く」という手順を取れるため、作業ミスで締め出されたときに再読み込みで戻せる余地があります。

同じ作業をコマンドで比べる

初期化と有効化

ufw は有効化した瞬間から既定のポリシーが効きます。SSH の許可を入れる前に有効化すると接続が切れるおそれがあるため、順番が重要です。

# ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH        # /etc/ufw/applications.d のアプリプロファイルを利用
sudo ufw enable
sudo ufw status verbose

# firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all

Web サーバーの公開

# ufw
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# firewalld（runtime で試してから permanent に反映）
sudo firewall-cmd --zone=public --add-service=http --add-service=https
sudo firewall-cmd --runtime-to-permanent

firewalld では --permanent を付けて書き込み、--reload で反映する方法もあります。--permanent だけを付けて --reload を忘れると、設定ファイルには書かれているのに今は効いていない、という状態になる点に注意してください。

特定の IP アドレスだけ SSH を許可

# ufw
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw delete allow OpenSSH

# firewalld（リッチルールで許可し、ゾーンの ssh サービスを外す）
sudo firewall-cmd --zone=public --permanent \
  --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" service name="ssh" accept'
sudo firewall-cmd --zone=public --permanent --remove-service=ssh
sudo firewall-cmd --reload

firewalld では、管理用 IP アドレスを trusted などの別ゾーンに送信元として割り当てる方法もあります。ゾーンの使い分けに慣れると、「この送信元にはこの許可」という整理がしやすくなります。

接続回数の制限

ufw には limit があり、同じ IP アドレスから短時間（30秒間に6回以上）に接続を試みると拒否します。SSH への総当たり対策の手軽な一歩になります。

sudo ufw limit OpenSSH

firewalld ではリッチルールの limit で記録や受け入れの頻度を制限できますが、ufw の limit と同じ挙動を一行で作る機能ではありません。どちらの場合も、本格的な総当たり対策には Fail2ban などログを見て遮断するツールを組み合わせるのが一般的です。

運用で差が出るポイント

ルールの確認と削除

ufw は sudo ufw status numbered で番号付きの一覧を表示し、sudo ufw delete 番号 で削除できます。1つの一覧で見渡せるのが利点です。firewalld はゾーンごとに --list-all で確認します。ゾーンが増えると全体を把握しにくくなるため、--list-all-zones で定期的に見直すと漏れを防げます。

ログ

ufw は sudo ufw logging on でログを有効にでき、Ubuntu では多くの場合 /var/log/ufw.log に記録されます。firewalld は sudo firewall-cmd --set-log-denied=all で拒否したパケットを記録でき、カーネルログ（journalctl -k など）で確認します。

Docker との組み合わせ

Docker でコンテナのポートを公開すると、Docker が独自に netfilter のルールを追加するため、ufw や firewalld のルールで拒否したつもりのポートに外部から到達できることがあります。これはどちらのツールでも起こり得る問題です。公開が不要なポートは 127.0.0.1:8080:80 のようにローカルアドレスにだけ割り当てる、Docker の公式ドキュメントにあるファイアウォール連携の注意点を確認する、外部から実際にポートスキャンして確かめる、といった対策をとってください。Docker と firewalld の連携方法は Docker のバージョンによって変わっています（2026年10月現在）。

締め出しへの備え

どちらを使う場合も、リモートで設定を変える前に、VPS やクラウドのコンソール接続（シリアルコンソールなど）が使えることを確認しておきます。firewalld では --timeout=300s のように時間制限付きで runtime ルールを追加でき、一定時間後に自動で消えるため、試験的な許可に向いています。設定ファイル（/etc/ufw/ や /etc/firewalld/）は変更前にバックアップし、可能ならステージング環境で同じ手順を試してから本番に適用します。

どちらを選ぶか

• ufw が向く：Ubuntu／Debian の単体サーバー、ルールが少ない Web サーバーや VPS、チームの多くが Ubuntu に慣れている
• firewalld が向く：RHEL 系のサーバー、複数のネットワークインターフェースや送信元ごとに許可を変えたい、runtime で試してから反映したい、Cockpit や構成管理ツールから操作したい
• ディストリビューションの標準に合わせる：特別な理由がなければ、OS の標準ツールを使うほうが、ドキュメントやサポート情報を見つけやすく、更新時の不整合も起きにくい

まとめ

• ufw も firewalld も netfilter を扱うフロントエンドで、同じサーバーで併用しない
• ufw は1つのルール一覧で即時反映、firewalld はゾーンと runtime／permanent の分離が特徴
• firewalld では --permanent の後の --reload 忘れ、ufw では SSH 許可前の enable に注意する
• Docker の公開ポートはどちらでもルールを素通りすることがあるため、外部から確認する
• 迷ったらディストリビューションの標準ツールを選び、変更前にバックアップとコンソール接続を確保する

• ufw でファイアウォールを設定する手順
• nftables でファイアウォールを設定する方法