ufwとfirewalldの使い方｜コマンド対応表とSSH締め出し対策

ufw と firewalld は、どちらも Linux カーネルのパケットフィルター（netfilter）を簡単なコマンドで操作するための「フロントエンド」です。 Ubuntu・Debian 系では ufw、RHEL・Rocky Linux・AlmaLinux・Fedora 系では firewalld が標準的に使われます。中身の仕組みは同じなので、片方を覚えればもう片方は「書き方の対応」を押さえるだけで使えます。

この記事では、ufw と firewalld の同じ操作を1つの表に並べた対応表を最初に示し、続けて SSH で締め出されないための手順チェックリスト、Docker の公開ポートが ufw のルールを通らない理由と対策、クラウドのセキュリティグループとの役割分担をまとめます。コマンドの構文は Ubuntu 24.04 の apt で入れた ufw 0.36.2 と firewalld 2.1.1 で、ufw --dry-run と firewall-offline-cmd を使って実際に確認し、その出力を載せています。

ufwとfirewalldのコマンド対応表

いちばん大きな違いは「永続化」です。ufw はコマンドを打った時点で設定ファイルにも保存されます。firewalld は --permanent なしだと「今だけ（runtime）」の変更で、再起動や --reload で消えます。

ufw・firewalld・nftables・iptablesの関係

flowchart TB
    U["ufw（Ubuntu / Debian）"] --> I["iptables コマンド（iptables-nft）"]
    F["firewalld（RHEL / Rocky / Fedora）"] --> N["nftables（nft）"]
    I --> N
    D["Docker"] --> I
    N --> K["Linux カーネルの netfilter"]

同じサーバーで ufw と firewalld を同時に有効にしないのが基本です。どちらも netfilter にルールを書くため、片方の変更がもう片方の想定とずれ、意図しない通信の通し方になります。使う方を1つ決め、もう片方は systemctl disable --now で止めます。

ufwの使い方

既定の状態を確認する

sudo apt-get install -y ufw
ufw version
sudo ufw status verbose

ufw 0.36.2
Copyright 2008-2023 Canonical Ltd.
Status: inactive

インストール直後は無効（inactive）です。既定のポリシーは /etc/default/ufw に書かれています。

IPV6=yes
DEFAULT_INPUT_POLICY="DROP"
DEFAULT_OUTPUT_POLICY="ACCEPT"
DEFAULT_FORWARD_POLICY="DROP"
DEFAULT_APPLICATION_POLICY="SKIP"

「受信は拒否・送信は許可」が既定です。つまり、許可ルールを入れずに ufw enable すると、SSH も含めて外からの接続がすべて止まります。

--dry-runで変換結果を確認する

--dry-run を付けると、設定を変えずに「どんな iptables ルールになるか」だけを表示します。

sudo ufw --dry-run allow OpenSSH | grep -E 'tuple|dport'

### tuple ### allow tcp 22 0.0.0.0/0 any 0.0.0.0/0 OpenSSH - in
-A ufw-user-input -p tcp --dport 22 -j ACCEPT -m comment --comment 'dapp_OpenSSH'

sudo ufw --dry-run allow from 203.0.113.10 to any port 5432 proto tcp | grep -E 'ACCEPT' | head -1

-A ufw-user-input -p tcp --dport 5432 -s 203.0.113.10 -j ACCEPT

limit は、同じ送信元から30秒以内に6回以上の新規接続があれば拒否するルールになります。

sudo ufw --dry-run limit 22/tcp | grep -E 'tuple|recent'

### tuple ### limit tcp 22 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --set
-A ufw-user-input -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 30 --hitcount 6 -j ufw-user-limit

インターフェース指定・送信の拒否・転送（route）も同じように確認できます。

### tuple ### allow tcp 443 0.0.0.0/0 any 0.0.0.0/0 in_eth0     ← allow in on eth0 to any port 443 proto tcp
### tuple ### deny tcp 25 0.0.0.0/0 any 0.0.0.0/0 out           ← deny out 25/tcp
### tuple ### route:allow tcp 80 172.17.0.2 any 0.0.0.0/0 in    ← route allow proto tcp from any to 172.17.0.2 port 80

アプリケーションプロファイル（サービス名）

sudo ufw app list
sudo ufw app info OpenSSH

Available applications:
  Bind9
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

Profile: OpenSSH
Title: Secure shell server, an rshd replacement
Description: OpenSSH is a free implementation of the Secure Shell protocol.

Port:
  22/tcp

一覧に出るのは、/etc/ufw/applications.d/ にプロファイルを置いたパッケージだけです（この環境では nginx などが入っていたため表示されています）。スペースを含む名前は sudo ufw allow "Nginx Full" のように引用符で囲みます。

ufwのよくあるエラー

上の3つは --dry-run 付きで実際に表示を確認しました。

ufwの基本セット（Webサーバーの例）

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH            # 先にSSHを許可（必須）
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw show added               # 有効化前に、追加したルールを確認
sudo ufw enable
sudo ufw status numbered

ufw enable を実行すると、SSH 接続中の場合は Command may disrupt existing ssh connections. Proceed with operation (y|n)? と確認されます。この確認が出たら、OpenSSH を許可済みかもう一度見てから y を押します。

番号で削除する場合は、status numbered で番号を確認してから delete 番号 にします。1つ消すと後ろの番号が繰り上がるので、複数消すときは毎回確認し直します。

sudo ufw status numbered
sudo ufw delete 3

この環境はコンテナのため、netfilter を有効にした状態での ufw enable・ufw status numbered の表示と、実際に通信が遮断されるかどうかは、ufw の公式ドキュメントとマニュアルの記述に沿って書いています。

firewalldの使い方

ゾーンとサービスの考え方

firewalld は「ゾーン（信頼度ごとのルールの入れ物）」にインターフェースや送信元を割り当て、ゾーンにサービスやポートを許可する仕組みです。

firewall-offline-cmdで設定を確認する

firewalld 本体（デーモン）が動いていない環境では、firewall-offline-cmd で永続設定のファイルを直接読み書きできます。オプションは firewall-cmd とほぼ同じです。

sudo apt-get install -y firewalld
firewall-offline-cmd --version
firewall-offline-cmd --get-default-zone
firewall-offline-cmd --get-zones
firewall-offline-cmd --list-all

2.1.1
public
block dmz drop external home internal public trusted work
public (default)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: dhcpv6-client ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

public ゾーンには最初から ssh と dhcpv6-client が許可されています。ufw と違い、有効化しただけで SSH が止まることはありません。

※ この検証環境では python3 が 3.11 に差し替えられていたため、/usr/bin/python3.12 /usr/bin/firewall-offline-cmd の形で実行しました。通常の Ubuntu・RHEL 系ではそのまま firewall-offline-cmd で動きます。

ポート・サービス・IP制限・レート制限を追加する

firewall-offline-cmd --add-service=http
firewall-offline-cmd --add-port=8080/tcp
firewall-offline-cmd --add-rich-rule='rule family="ipv4" source address="203.0.113.10" port port="5432" protocol="tcp" accept'
firewall-offline-cmd --add-rich-rule='rule service name="ssh" limit value="10/m" accept'
firewall-offline-cmd --zone=trusted --add-source=192.0.2.0/24
firewall-offline-cmd --list-all

success
success
success
success
success
public (default)
  ...
  services: dhcpv6-client http ssh
  ports: 8080/tcp
  ...
  rich rules: 
    rule family="ipv4" source address="203.0.113.10" port port="5432" protocol="tcp" accept
    rule service name="ssh" accept limit value="10/m"

保存先の /etc/firewalld/zones/public.xml は次のようになりました（抜粋）。

<zone>
  <short>Public</short>
  <service name="ssh"/>
  <service name="dhcpv6-client"/>
  <service name="http"/>
  <rule family="ipv4">
    <source address="203.0.113.10"/>
    <port port="5432" protocol="tcp"/>
    <accept/>
  </rule>
  <rule>
    <service name="ssh"/>
    <accept>
      <limit value="10/m"/>
    </accept>
  </rule>
  <forward/>
</zone>

リッチルール（rich rule）は「送信元・ポート・動作」を1行で書ける詳しいルールです。IP 制限やレート制限はリッチルールで書きます。limit value="10/m" は「1分あたり10回まで受け付ける」という意味です。

firewalldのよくあるエラー

firewall-cmd をデーモンなしで実行したところ、この環境では Error: DBUS_ERROR: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory と表示されました。firewall-cmd は D-Bus 経由でデーモンに指示するため、デーモン（と D-Bus）が動いていないと使えません。

runtimeとpermanentの使い分け

「runtime で試す → 接続を確認 → --runtime-to-permanent で保存」の順にすると、設定を誤っても --reload か再起動で元に戻せます。これは次の SSH 締め出し対策にも使えます。

SSH締め出しを防ぐチェックリスト

リモートのサーバーでファイアウォールを設定するときは、自分が使っている SSH 接続を止めないことが最優先です。

at が入っていない場合は、systemd の一時タイマーでも同じことができます。

# 5分後に ufw を無効にする一時タイマー（確認できたら止める）
sudo systemd-run --unit=ufw-safety --on-active=5min /usr/sbin/ufw disable
# 接続を確認できたら
sudo systemctl stop ufw-safety.timer

firewalld で runtime だけの変更にしておけば、締め出されてもサーバーの再起動で permanent 設定（変更前）に戻ります。クラウドの仮想マシンなら、コンソール画面からの再起動やシリアルコンソールで操作できます。

at・systemd-run の自動解除と、別セッションからの接続確認は、この環境では systemd・SSH サーバーが動いていないため、手順は ufw・firewalld・systemd-run の公式ドキュメントの仕様に沿って書いています。

設定を全部リセットするときの手順（firewalld）

「全部リセット」は、対応表の中でいちばん取り返しがつきにくい操作です。ufw の ufw reset は、ルールファイルを日付つきの名前で退避してから既定のファイルに戻し、ufw 自体を無効にします（確認の問い合わせが出ます）。firewalld で同じことをするなら、設定ファイルを手で消すのではなく、--reset-to-defaults を使ってください。 /etc/firewalld/ は管理者が変えた設定の保存場所で、ここを消すとカスタムゾーン・サービス・ポートの設定がすべて失われます。

手順は次の4つです。

# 1. 設定を丸ごと控えておく（戻すときはこのディレクトリを戻す）
sudo cp -a /etc/firewalld /root/firewalld.bak.$(date +%Y%m%d)

# 2. コンソール（クラウドのシリアルコンソール・仮想マシンの画面）から入れることを確かめておく
#    リセットは permanent 設定を書き換えて即反映するので、再起動では元に戻らない

# 3. 既定の設定に戻す（既定の public ゾーンは ssh を許可しているので、22番の SSH は通る）
sudo firewall-cmd --reset-to-defaults

# 4. SSH を 22 以外で動かしている場合は、同じセッションのまますぐに開け直す
#    （--reload は通信の状態を保つので、今つながっている SSH は切れない）
sudo firewall-cmd --add-port=2222/tcp --permanent && sudo firewall-cmd --reload

4 のあと、必ず別の端末から新しく SSH 接続して確かめてから、元のセッションを閉じてください。SSH のポートを変えている場合は、3 と 4 の間で新しい接続ができない状態になるので、間を空けないことが大切です。

この手順は firewalld 2.1.1 の firewall-offline-cmd --reset-to-defaults で確かめました。カスタムゾーン・ポート・サービスを追加したあとに実行すると、/etc/firewalld/zones/*.xml と services/*.xml が .old に退避され、firewalld.conf は DefaultZone=public に戻り、/usr/lib/firewalld/ の既定ファイルは変わりませんでした。一方、/etc/firewalld/zones/ を手で消した場合は、firewalld.conf に残った既定ゾーン名が見つからず「Default zone 'myzone' is not valid. Using 'public'.」というエラーが出て public に切り替わり、追加していたポートの設定は戻せませんでした。firewall-cmd --reset-to-defaults が入った版は、公開されているソースで 1.2.0 には無く 1.3.0 にあることを確認しています。

Dockerの公開ポートがufwを通らない問題と対策

なぜ通ってしまうのか

docker run -p 8080:80 nginx のようにポートを公開すると、ufw で 8080 を許可していなくても外から接続できます。 理由はパケットの通り道にあります。

flowchart LR
    P["外からのパケット（宛先:8080）"] --> PR["nat PREROUTING（Docker の DNAT で宛先をコンテナIP:80 に変換）"]
    PR --> FW["filter FORWARD（DOCKER-USER → DOCKER のチェーン）"]
    FW --> C["コンテナ"]
    PR -.->|ホスト宛ての場合だけ| IN["filter INPUT（ufw のルールはここ）"]

ufw の通常のルール（ufw allow など）は、ホスト自身宛ての通信が通る INPUT に入ります。Docker は宛先をコンテナの IP に書き換えるため、パケットは INPUT ではなく FORWARD を通り、ufw の INPUT のルールに当たりません。firewalld の環境でも、Docker は専用の docker ゾーンを作り、公開ポートは public ゾーンの許可とは別に扱われます。

対策の選び方

外に出す必要がないポートは 127.0.0.1: を付けて公開するのがいちばん確実です。外から見えるのは、前に置いたリバースプロキシ（80/443）だけになります。

DOCKER-USERチェーンで送信元を絞る

Docker は、自分が作るルールより先に評価される DOCKER-USER チェーンを用意しています。ここにルールを入れると、公開ポートへのアクセスを制限できます。ufw を使っている場合は、/etc/ufw/after.rules の末尾に追記すると ufw の再読み込み時にも保たれます。

# /etc/ufw/after.rules の末尾に追記（eth0 は外向きのインターフェース名に合わせる）
*filter
:DOCKER-USER - [0:0]
-A DOCKER-USER -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN
-A DOCKER-USER -i eth0 -s 203.0.113.0/24 -j RETURN
-A DOCKER-USER -i eth0 -j DROP
COMMIT

sudo ufw reload
sudo iptables -S DOCKER-USER

この DOCKER-USER の設定と -p の素通りについては、Docker デーモンと netfilter を使った確認ができない環境のため、Docker 公式ドキュメント（Packet filtering and firewalls）の DOCKER-USER の説明に沿って書いています。Docker のバージョンやファイアウォールのバックエンド（iptables / nftables）によってチェーン名や挙動が異なる場合があるので、適用前に sudo iptables -S DOCKER-USER で存在を確認してください。

クラウドのセキュリティグループとの役割分担

クラウドの仮想マシンでは、ホストの外側（セキュリティグループ、ネットワークACL など）とホストの内側（ufw・firewalld）の2段構えにできます。

おすすめの分担は、セキュリティグループで「SSH は管理元IPだけ、Web は 80/443 だけ」と入口を絞り、ufw・firewalld では同じ方針を重ねたうえで、レート制限・ログ・送信制限を追加する形です。両方で同じ方針にしておくと、片方の設定を誤っても、もう片方で守られます。

よくあるトラブルと確認ポイント

よくある質問

Q. Ubuntu で firewalld を使ってもよいですか？ A. 使えます。apt で firewalld を入れれば動きます。ただし ufw と同時に有効にせず、どちらか1つにします。複数のディストリビューションのサーバーを同じ手順で管理したい場合は、firewalld にそろえる方法もあります。

Q. ufw の limit と firewalld の limit は同じ意味ですか？ A. 少し違います。ufw の limit は「同じ送信元から30秒以内に6回以上の新規接続で拒否」という固定の条件です（--dry-run の出力で --seconds 30 --hitcount 6 を確認）。firewalld のリッチルールの limit value="10/m" は、受け付ける頻度の上限を自分で指定します。

Q. iptables のコマンドで直接ルールを追加してもよいですか？ A. ufw や firewalld が有効な環境では、直接追加したルールは ufw の再読み込みや firewalld の --reload で消えたり、順番がずれたりします。ufw なら /etc/ufw/before.rules・after.rules、firewalld ならダイレクトルールやポリシーに書くと管理がまとまります。

Q. ファイアウォールの変更を手元で試す方法はありますか？ A. ufw は --dry-run で変換後のルールを、firewalld は firewall-offline-cmd で設定ファイルの変化を確認できます。この記事の出力もこの2つで取ったものです。通信が実際に止まるかどうかは、仮想マシンなど締め出されても戻せる環境で確かめると安心です。

まとめ

• ufw と firewalld はどちらも netfilter のフロントエンド。同じサーバーではどちらか1つを使う
• ufw はコマンドがそのまま永続化、firewalld は --permanent が必要。runtime で試してから --runtime-to-permanent が安全
• ufw は既定で受信拒否。enable の前に必ず ufw allow OpenSSH
• 締め出し対策は 先に許可 → 自動解除の仕掛け → 今のセッションを残して別端末で確認
• Docker の公開ポートは ufw の INPUT を通らない。127.0.0.1: バインドか DOCKER-USER で制限
• クラウドのセキュリティグループで入口を絞り、ホスト側でレート制限やログを足す2段構えにする
• 構文は ufw --dry-run と firewall-offline-cmd で事前に確認できる

株式会社RJCでは、サーバーを安全に運用するための基礎知識を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。